Re: [cors-tests] Add 304 tests for CORS (#1740)

@annevk I think the changes would be in 4.3 HTTP network or cache fetch, around step 7. 

That assumes that a cache entry, when present, can only be "complete" or "incomplete", but there's another axis -- "fresh" or "stale".

What is specified handles "fresh", but if it's stale, the request still needs to be made, but as a conditional request, and the response if a 304 needs to be combined with the cached response, as per <http://httpwg.github.io/specs/rfc7234.html#freshening.responses>.

That would handle *this* issue. There's a lot more that isn't covered, such as:

* Serving stale responses when the network is down - <http://httpwg.github.io/specs/rfc7234.html#serving.stale.responses>
* Handling Vary - <http://httpwg.github.io/specs/rfc7234.html#caching.negotiated.responses>
* Cache invalidation - <http://httpwg.github.io/specs/rfc7234.html#invalidation>
* Request cache-control - <http://httpwg.github.io/specs/rfc7234.html#cache-request-directive>

Etc. Ideally you wouldn't need to re-specify all of caching, but you do need to accommodate the major features if you're going to go to the level of detail that you have.

Does that make sense generally? If so, I'll start a pull.

Also, in step 8, what are "resume headers"?

View on GitHub: https://github.com/w3c/web-platform-tests/pull/1740#issuecomment-94182068

Received on Saturday, 18 April 2015 17:02:29 UTC