Should a 304 Not Modified response to a CORS request contain CORS headers?

user_81491 0
Viewed 311

Say that a client has made a cross-origin request to read an object, which passed, and the client cached the results. Now, the client makes a new request to read the object, and the previous result is still cached in the browser.

The client makes this request:

GET /pony.png HTTP/1.1

Host: server.com
Origin: field.com
If-None-Match: "etag-abcd"

Now, say that "etag-abcd" is valid for the object. The server replies

HTTP/1.1 304 Not Modified

Etag: "etag-abcd"
Date: Tue, ...
Expires: Wed, ...

If this is a valid cross-origin request, is the server obliged to provide appropriate Access-Control-Allow-Origin and other headers? Or, is the client obliged to respect the CORS headers that would have come along with the original, cached result?

The Fetch standard is quite complex, but it contains phrases like "As the CORS check is not to be applied to responses whose status is 304 or 407...." that make me suspect fresh CORS headers would not be necessary in a 304 response.

On the other hand, my reading of §4.6, step 10.4, suggests that the headers in the 304 response take precedence and even replace any cached result in the headers of the original GET response.

cors fetch http
1 Answers

Yeah, HTTP-network-or-cache fetch does indeed handle the 304 response, but it ends up returning the updated stored response, upon which the CORS check is performed in HTTP fetch. So for a typical 304 no CORS headers would be needed as they would already be present on the stored response.

There are some edge cases:

  1. The server could return a 304 response even when the client does not perform a validation request. In that case it would have to have CORS headers as the CORS check would be performed on the 304 response (and not a stored response updated with the 304 response).
  2. The 304 response could update the CORS headers. (I'm not sure we have adequate test coverage for this scenario.)
Anne_236070
Related