1412828 - Simple cross-origin request via fetch API fails on 307 redirect

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Ben]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38

Steps to reproduce:

Use fetch API to GET resource, which is redirected (with a 307).


Actual results:

Fetch throws a network error (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://example.com’). The network panel shows two network requests, the first has a 307 response and the second 200. The reason given is wrong, as the headers clearly show a correct Access-Control-Allow-Origin header in both responses. However, the 'origin' header is spelled with lower-case 'o' in the first request and upper-case 'O' in the second.


Expected results:

The fetch request should have resolved without error.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

We need more a test case here.  Exactly what code is being executed on what site?  A reproduceable case in glitch.com or something like it would be best.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hello Ben, thanks for reporting this. Would you please provide a simple test case and more information per comment 1? It helps a lot to make this issue more actionable.

Comment 3

[Ben]

Hi, here's some more info and a test case, sorry for the delay.

I've narrowed the issue down, the error occurs under the following conditions:

1. cross-site fetch request
2. request returns with a redirect (307, 303, or 302, probably all 3xx)
3. the redirect target location's domain differs from the original request domain
3. the 'access-control-allow-origin' header is set to the correct origin, _not_ to '*'

This results in the following error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://example.net/. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://example.com’).

Steps to reproduce:

1. install plugin to manipulate response headers (https://addons.mozilla.org/de/firefox/addon/moz-rewrite-js/)(or configure a webserver to do the same)
2. use the following rule set for responses.js:
[
    {
        "url" : /^https:\/\/httpstat.us/,
        "headers" : {
          "access-control-allow-origin" : "https://example.com",
          // "location" : "https://httpstat.us"
          "location" : "https://example.net"
        }
    },
    {
        "url" : /^https:\/\/example.net/,
        "headers" : {
          // "access-control-allow-origin" : "*",
          "access-control-allow-origin" : "https://example.com",
        }
    }
]
3. open https://example.com in firefox
4. run the following in the console: fetch('https://httpstat.us/307').then((response) => { console.log(response.status) });

Some remarks: 
1. If 'access-control-allow-origin' is set to '*' for the final response, all works as expected
2. There is a second bug in the error message (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://example.com’). The domain given is actually what is specified in the 'access-control-allow-origin' header, not what the actual origin is. You can see this by changing the 'access-control-allow-origin' header in the second rule to, e.g., 'https://foo.com': (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://foo.com’). This should read something like 'Reason: CORS header ‘Access-Control-Allow-Origin’ is set to ‘https://foo.com’, which does not match ‘https://example.com’'