Http/2 push cache & etag

(Felipe Gasper) #1

I’m learning http/2 and have a question about caching.

The PUSH_PROMISE frame gives to the client the request headers, but does it give the client any way to judge whether what’s “PROMISE”d is, in fact, what the client has cached?

Specifically: could PUSH_PROMISE send along something like the Etag, then the client would decide whether it needs to request a new copy of the resource?

Example:

  1. Client requests page, receives foo.js with Etag 123qwe.

  2. Client requests page again. Server starts pushing foo.js and sends the Etag 123qwe. Client sees that it already has that version of foo.js cached and sends a RST_STREAM to cancel the send.

  3. A while later, client requests page again. Server starts pushing foo.js but this time sends Etag 234wer. The client sees that foo.js has changed, so it accepts the newly-pushed version of the file.

Is there nothing like this in place? Or do we just have to continue with the old URL-based cache expiration hacks?

(system) closed #2

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.