Should Push responses be cached?

[szmarczak]

Push streams are very useful while using a browser. We receive stylesheets, scripts, HTML content simultaneously.

Should Push responses be cached? Is there any real use case?

[pietermees]

Maybe we could allow someone to provide an external cache implementation just like for the normal HTTP cache? That would allow consumers of the library to determine the right caching strategy?

Check out this post for an easy to understand description of the various caches: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

[szmarczak]

Maybe we could allow someone to provide an external cache implementation just like for the normal HTTP cache?

That would be cool. I just wonder how to do that. Should this be Agent-level?

Check out this post for an easy to understand description of the various caches:

Nice tips. But is there any real use case? I mean for browsers it's useful. Imagine you're scraping some websites. You don't need the images, do you? If you want to get them you can make another request. Only I can think of is preloading some data to display.

I think push streams should be off by default. But we could enable it's support through Agent (there would be a new function agent.onSession(session) and users would just override agent.request(...)}.

[pietermees]

Yeah, I agree, definitely not arguing for all those caches to exist. I guess my only point is that the PUSH cache is connection-specific while the HTTP cache is shared across all connections in a browser.

I agree that PUSH can be off by default (note that you can signal support for PUSH in the settings you send to the remote host, we should probably indicate that we don't support PUSH in those settings for efficiency reasons).

If the PUSH cache is per connection in the browser, I guess that maps to a session in Node?

[szmarczak]

If the PUSH cache is per connection in the browser, I guess that maps to a session in Node?

That's right.