Closed Bug 1311566 Opened 4 years ago Closed 3 years ago

304 http response requiring cors headers (against spec?)


(Core :: Networking: HTTP, defect)

49 Branch
Not set





(Reporter: urkle, Unassigned)


(Whiteboard: [necko-next])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

var xhr = new XMLHttpRequest();"GET", "");
xhr.onreadystatechange = function() { console.log('state', xhr); }
xhr.onload = function() {
     console.log('load', xhr, xhr.getResponseHeader('ETag')); 
     var etag = xhr.getResponseHeader('ETag');

    var xhr2 = new XMLHttpRequest();"GET", "");
    xhr2.setRequestHeader("If-None-Match", etag);
    xhr2.onreadystatechange = function() { console.log('state', xhr2); }
    xhr2.onload = function() { console.log('load', xhr2); }

server-side PHP script


header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: GET");
header('Access-Control-Allow-Headers: if-none-match');
header("Access-Control-Expose-Headers: Etag");

    $etag = 'DEADBEEF2';

    if ($_SERVER['HTTP_IF_NONE_MATCH'] == $etag)
        header("HTTP/1.1 304 Not Modified");
        header("Etag: $etag");

Actual results:

I received a CORS error for the second request

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Expected results:

The second request should pass..

More info...

The server is running Apache+PHP which, apache strips out all Cors headers (per RFC )

There is confusion apparently in the CORS spec as the "fetch" spec that CORS grew out of states that the access headers are NOT to be in 304, or 407 responses..

However, the main CORS spec makes no mention of that

So, What IS the appropriate way to handle this we can have clear documentation to send to Apache group to make sure their web server is complying with the correct specification.
Apache HTTPd bug where this is being discussed.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Reading the comments in these wpt pull requests it seems browsers expect the 304 to be governed by CORS:

I see, though, neither of these have been landed yet.

Personally I'm not sure why we would want to loosen this restriction.  The RF7232 does not explicitly mention CORS.  It just says non-caching headers should be stripped.  Its likely it was written without CORS in mind at all.

Anne, any thoughts?
Flags: needinfo?(annevk)
Whiteboard: [necko-next]
We changed the Fetch Standard (/TR/cors/ is no longer maintained and is best ignored) in for the case where the browser handles the 304 and turns it into a 200. As far as I know browsers do not require CORS headers to be present for that.

Now, for the case where you implement conditional requests by yourself (by setting certain headers or playing with request's cache mode) you might get a 304 back that the browser won't turn into a 200. That 304 will still be required to have CORS headers.

I should maybe try to clarify that distinction in Fetch somehow.
Flags: needinfo?(annevk)
Note also that the above referenced tests, while great, don't test this scenario. We need new tests for that.
Given all browsers do the same thing here. If the Fetch Standard is still unclear please file an issue at as this is not a bug in Firefox.
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.