Access-Control-* headers incorrect for Request URL
Reported by
roberto....@gmail.com,
Sep 8 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Have Network tab in inspector running 2. Make a request to a page that makes an XHR POST to a remote API 3. Note the OPTIONS request _lists_ Access-Control-* headers even though the remote API doesn't include them in the response 4. See `XMLHttpRequest cannot load https://siteB/foo. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://siteA' is therefore not allowed access. The response had HTTP status code 500.` in the console 5. Scratch head 6. Make OPTIONS request with curl, e.g. `curl -i --insecure -XOPTIONS -H 'Access-Control-Request-Headers: content-type' -H 'Access-Control-Request-Method: POST' https://siteB/foo` 7. Note the curl OPTIONS request _does not list_ Access-Control-* headers. 8. Sigh / Aha! / Harumph. What is the expected behavior? The Developer Tools network tab should only show the selected request's response headers. What went wrong? It looks like the inspector's request headers tab is overlaying the current request's headers with previous headers, but I don't know. Did this work before? N/A Chrome version: 52.0.2743.116 Channel: n/a OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 22.0 r0
,
Sep 12 2016
in the headers tab, try toggling to "view source" in the response headers. Is that more what you'd expect?
,
Oct 1 2016
Can you give us a live demo to sample with? We are unable to reproduce this issue.
,
Oct 6 2016
I will attempt to reproduce and put a demo together. Thanks.
,
Dec 2 2016
Closing due to no feedback for a while. Feel free to ping back on here and I'll reopen it if still reproducible. |
|||
►
Sign in to add a comment |
|||
Comment 1 by elawrence@chromium.org
, Sep 8 2016