4 ms·
Jake mentions one of the reasons in his post (that's linked elsewhere) Push is on a connection (not request) basis so if the connection is authoritative for mu
by youngtaff 2y ago
Jake mentions one of the reasons in his post (that's linked elsewhere)
Push is on a connection (not request) basis so if the connection is authoritative for multiple hosts i.e. they share a cert in the way low cost Cloudflare plans used to (perhaps still do?) then you can push resources for another site
Even without that issue you wouldn't want every resource that gets pushed to end up in the browser cache by default as it leaves open all sorts of malicious behavior e.g. just keep pushing until the browser cache is full of crap etc.
- jauntywundrkind 2y agoPush_promise frame includes an optional stream identifier (as well as the promise stream identifier). https://httpwg.org/specs/rfc9113.html#PUSH_PROMISE https://httpwg.org/specs/rfc9113.html#PUSH_PROMISE Not only is it possible to associate a push with a request, but this is crucial to Web Push Protocol (which powers the Push API in browsers). https://datatracker.ietf.org/doc/html/draft-ietf-webpush-protocol#section-6 https://datatracker.ietf.org/doc/html/draft-ietf-webpush-pro... I don't place a ton credence in the malicious behavior assertions. A web page can already request a colossal number of large resources, flood the cache. Yes the browser gets to dispatch requests as it pleases. But having push limit it's cache size also seems not absurdly hard, and like something that wouldn't impede healthy usage much.
- hedora 2y agoI wonder if you can use this to implement cross-site-cookies. (A pushes cookie data to B’s cache with a well known name, then B fetches A data from local cache).