- From: Felipe Gasper <felipe@felipegasper.com>
- Date: Thu, 21 Dec 2017 23:55:43 -0500
- To: Matthew Kerwin <matthew@kerwin.net.au>
- Cc: ietf-http-wg@w3.org
> On Dec 21, 2017, at 7:58 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote: > > On 22 December 2017 at 08:51, Felipe Gasper <felipe@felipegasper.com> wrote: >> Hello, >> >> Does HTTP/2 expect that a browser that: >> >> >> 1) Receives a PUSH_PROMISE with if-none-match = "hahaha" >> >> 2) Has that resource cached but with etag = "qweqwe" >> >> >> … will accept the new copy of the resource rather than sending RST_STREAM and using its cache? >> >> I’ve been testing this and can’t seem to get it to work this way. It keeps using the cache every time, even when I send a new etag. I’ve dug around several articles today on HTTP/2 caching, and I can’t find this level of detail in any of them. I’m not sure if my server setup is at fault, if the browsers are at fault, or if this just isn’t how it’s meant to work. >> >> Thank you! >> >> -Felipe Gasper >> Mississauga, Ontario > > Hi Felipe, > > Does the pushed response include the etag:"hahaha" header field, and > all the other cache-control stuff? I would imagine that that's more > important to the browser than whatever was in the virtual request > (although I'm not a browser person, so I can't say for sure.) > Hi Matthew, Yes, the initial pushed response has etag and cache-control. The browser (Chrome, FF, and Safari) does cache correctly when the response doesn’t change; the problem is that the browser uses the cache even when the etag/if-none-match changes. Going by Benedikt’s response, it sounds like dependence on etag in http/2 is something that isn’t envisioned to happen widely. :-/ -Felipe
Received on Friday, 22 December 2017 04:56:13 UTC