Closed Bug 1311566 Opened 4 years ago Closed 3 years ago

304 http response requiring cors headers (against spec?)

Categories

(Core :: Networking: HTTP, defect)

49 Branch
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: urkle, Unassigned)

Details

(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();
xhr.open("GET", "https://example.com/test.php");
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();
    xhr2.open("GET", "https://example.com/test.php");
    xhr2.setRequestHeader("If-None-Match", etag);
    xhr2.onreadystatechange = function() { console.log('state', xhr2); }
    xhr2.onload = function() { console.log('load', xhr2); }
    xhr2.send();
}
xhr.send();

server-side PHP script

<?php

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");

if ($_SERVER['HTTP_METHOD'] == 'OPTIONS')
{
}
else
{
    $etag = 'DEADBEEF2';

    if ($_SERVER['HTTP_IF_NONE_MATCH'] == $etag)
    {
        header("HTTP/1.1 304 Not Modified");
    }
    else
    {
        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 https://example.com/test.php. (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 http://tools.ietf.org/html/rfc7232#section-4.1 )

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..

https://fetch.spec.whatwg.org/#cors-protocol

However, the main CORS spec makes no mention of that

https://www.w3.org/TR/cors/#resource-sharing-check

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.  https://bz.apache.org/bugzilla/show_bug.cgi?id=51223
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:

https://github.com/w3c/web-platform-tests/pull/1400
https://github.com/w3c/web-platform-tests/pull/1740

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 https://github.com/whatwg/fetch/pull/141 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 https://github.com/w3c/web-platform-tests/pull/5005 all browsers do the same thing here. If the Fetch Standard is still unclear please file an issue at https://github.com/whatwg/fetch/issues/new as this is not a bug in Firefox.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.