Re: [whatwg/fetch] Http cache (#496)

I think I've got a rough work list for tests:

* [ ] Do credentials form part of the cache key?
* [ ] Are If-None-Match and If-Modified-Since sent correctly?
* [ ] Are cached responses invalidated?
* [ ] Are response headers updated on a 304?
* [ ] Are stale responses used when there's a network error?
* [ ] Is partial content handled correctly, and If-Range, etc. generated?
* [ ] Are non-200 status codes cached?
* [ ] Is Vary handled correctly?
* [ ] Are Cache-Control request directives respected?
* [ ] Is the precedence of Expires and max-age handled correctly?
* [ ] Is heuristic caching done?
  * [ ] Is the 'public' response directive honoured?
* [ ] Is CC: no-store handled correctly?
* [ ] is no-cache handled correctly in requests and responses?

The rest seems to be pretty well covered y fetc/api/request-cache.js.

I've already written and stashed a few tests. Some notes:

### Invalidation

Chrome partially implements; it invalidates the cache upon a successful PUT or unrecognised method (e.g., FOO). Firefox and Safari TP do not.

### Credentials in the Cache Key

Firefox implements; Chrome and Safari TP appear not to. This could be because it's spec'd and tested based upon the credentials flag; they may be looking for the actual credentials. Will play with it a bit more.

### Using Stale Responses on a Network Error

This isn't implemented, AFAICT, although the responses generated by the framework are extremely stale, and that may be playing into it. It might be best to take this out of the spec for now; it's allowed but not mandated by HTTP.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/496#issuecomment-284953973