Re: CORS and 304

On Tue, Dec 10, 2013 at 1:05 AM, Mark Nottingham <mnot@mnot.net> wrote:
> The problem comes in when you want to do your own cache and generate your own conditionals (e.g., If-None-Match); since CORS needs to happen before the response is exposed to the app (and therefore the in-app cache), you're kind of stuck.

Uhuh.


> XHR says:
>
>> For 304 Not Modified responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content. The user agent must allow author request headers to override automatic cache validation (e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through. [HTTP]

Which is awfully vague. We should be explicit about the headers. And
ideally we provide a more clear cut flag I think exposed to the API.


> Cache validation driven by the author requires the CORS headers to be on the 304, but as discussed this isn't realistic for many origin servers (i.e., 304s are automatically generated), and if there's a caching proxy server that generates the 304, it's practically impossible. So the answer might be "Don't do that [cross-origin validating requests from an authored cache]."

Software could be updated in due course, but yeah, for now it might be hard.


> Fetch says much the same thing, but AIUI ServiceWorker should be OK, because AIUI all of this machinery is hidden behind CrossOriginResponse in the Cache. Alex?

That depends on the exact semantics of the new networking API that we
may or may not introduce.


-- 
http://annevankesteren.nl/

Received on Thursday, 12 December 2013 15:55:33 UTC