Subject: HTTP2: ETag, If-None-Match, and RST_STREAM

From: Felipe Gasper <[email-masked]>
Date: Thu, 21 Dec 2017 17:51:43 -0500

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

---

From: Benedikt Christoph Wolters <[email-masked]>
Date: Fri, 22 Dec 2017 01:52:11 +0100

That is an interesting question and probably at the current stage very
implementation-specific (see e.g. [1])

You may also want to look at a previous discussion regarding this topic [2].

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=232040
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0522.html

Why would a user agent cancel a pushed stream with hahaha?

Qapla'!
Benedikt

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 22 Dec 2017 10:58:02 +1000

>         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,…

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.)

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Felipe Gasper <[email-masked]>
Date: Thu, 21 Dec 2017 23:55:43 -0500

> On Dec 21, 2017, at 7:58 PM, Matthew Kerwin <[email-masked]> wrote:
> 

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