5 ms·

I never found the explanations given for why HTTP/2 Push failed compelling. Google usually just refers to a blog post from Jake Archibald [1], but that post see

I never found the explanations given for why HTTP/2 Push failed compelling. Google usually just refers to a blog post from Jake Archibald [1], but that post seems to call out all the ways browsers poorly implemented it rather than reasons the protocol itself wouldn't work. Browsers already support preload links, which should function effectively the same as a Push header. Why couldn't that same code have been used for Push, including all the existing handling for things like caching and authorization headers that Jake called out as challenges with the 2017 implementations? [1] https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

youngtaff 2y ago
For security reasons pushed resources have to be treated as a special case until they're claimed by the page, amongst other things this means they need a separate cache until they're claimed
- paulddraper 2y ago
  Explain why security demands a separate cache?
  - bawolff 2y ago
    Cache poisioning attacks.
    - paulddraper 2y ago
      Oh I see. Push was not limited to the same host. Which would have been an easy fix.
      - bawolff 2y ago
        Connections arent limited to the same (virtual) host. Additionally, to prevent cross page tracking, browsers use a separate cache for subresources loaded from different top level domains. Anyways, it is trickier than it sounds at first glance.
        paulddraper 2y ago
        > Connections arent limited to the same (virtual) host. Huh? Doesn't HTTPS and SNI effectively require that?
        bawolff 2y ago
        Its a minor point, since the rules are quite strict so its probably not a security issue, but no, due to connection coalescing, one connection can serve multiple virtual hosts. See https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ https://daniel.haxx.se/blog/2016/08/18/http2-connection-coal...
- _heimdall 2y ago
  That's an interesting challenge. Is the Push header being included on the document request not enough to consider it a secure resource? I could see this being a concern with secondary requests that haven't been claimed by the document, say a stylesheet with Push headers to preload font files. I'm not quite sure how it would get into that state with the stylesheet being requested without the page having claimed the request, but is that the security concern?
  - 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 ago
      Push_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 ago
        I 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).
aseipp 2y ago
Preload headers DO NOT function "effectively the same" the same as HTTP/2 Push. Yes they have similar outcomes, no that does mean they function the same. They are related, but are not actually that similar except in the most trivial ways like using the word "Preload" - HTTP/2 Push: When the server thinks a client needs the resource, it pushes it into the client proactively, avoiding one round trip for the resource. The goal is to improve latency by sending the resource actively, independently of any DOM->render pipeline that would trigger the fetch. - Preload header: When the client requests a resource, the server delivers the page body, but it also tells it what it can load in parallel before parsing or JS eval. The goal is to improve latency by moving up the "fetch" stage, before the parse->DOM->render pipeline that would trigger the fetch. And beyond those two, over the past few years a new kid has appeared on the block: - 301 Early Hints: When the client requests a resource, the server sends a Preload hint telling it what to load before it even finishes generating the response. A 301 is delivered before the body is fully delivered, before even the first byte. The goal is to improve latency even further by moving the fetch stage up even earlier in the pipeline. Yes, they attack the same soft spot, but mechanically there is a VERY big difference between server-initialization and client-initialization, and between along-with-body and before-first-byte. (Obviously, 301s and Preloads are closer than anything.) Ignore the security stuff. The simplest reason HTTP/2 Push isn't so great is because it's not very good at accomplishing its goal. This is because browsers employ an ancient technique, originally written in hieroglyphs, called "caching", which means that the browser just won't request a resource if it already has it. A cache hit is the ultimate reduction in latency. But only the client browser knows what is in its cache, the server has no idea. With Push, you run a very real possibility of sending resources that aren't needed, overall losing efficiency. With 301s/preloads, you at worst receive a few wasted bytes from the useless headers. It's both much easier to get right, and much less costly if you get it wrong. It's also complicated to implement on top of all the other stuff. Preloads and 301s are vastly simpler and much more targeted additions to the HTTP stack, and HTTP is only useful insofar as implementations are compatible. So 301s/Preload are significantly easier to support and achieve much of the same purported benefits.
- CodesInChaos 2y ago
  "Early Hints" is 103. 301 is "moved permanently".
jauntywundrkind 2y ago
I find the excuse for unshipping especially ridiculous because developers never had a good chance to make use of Push! We can't see Pushes coming at us, cant be responsive to them! https://github.com/whatwg/fetch/issues/51 https://github.com/whatwg/fetch/issues/51 It also feels like the use case everyone was focusing on/acknowlegding of content delivery had plenty of opportunities left. There weren't very many visible public attempts! Very few people had access to libraries or starting places to begin to jump in, figure out what to Push!
_heimdall 2y ago
Well my understanding of the Push spec seems to have been as rusty as the spec itself. I forgot it was actually pushing full content that the server expects the client will need, I had it in my head that the request would just include a header that hints at dependencies similar to preload links in the <head>

youngtaff 2y ago

For security reasons pushed resources have to be treated as a special case until they're claimed by the page, amongst other things this means they need a separate cache until they're claimed

paulddraper 2y ago
Explain why security demands a separate cache?
- bawolff 2y ago
  Cache poisioning attacks.
  - paulddraper 2y ago
    Oh I see. Push was not limited to the same host. Which would have been an easy fix.
    - bawolff 2y ago
      Connections arent limited to the same (virtual) host. Additionally, to prevent cross page tracking, browsers use a separate cache for subresources loaded from different top level domains. Anyways, it is trickier than it sounds at first glance.
      - paulddraper 2y ago
        > Connections arent limited to the same (virtual) host. Huh? Doesn't HTTPS and SNI effectively require that?
        bawolff 2y ago
        Its a minor point, since the rules are quite strict so its probably not a security issue, but no, due to connection coalescing, one connection can serve multiple virtual hosts. See https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ https://daniel.haxx.se/blog/2016/08/18/http2-connection-coal...
_heimdall 2y ago
That's an interesting challenge. Is the Push header being included on the document request not enough to consider it a secure resource? I could see this being a concern with secondary requests that haven't been claimed by the document, say a stylesheet with Push headers to preload font files. I'm not quite sure how it would get into that state with the stylesheet being requested without the page having claimed the request, but is that the security concern?
- 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 ago
    Push_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 ago
      I 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).

aseipp 2y ago

Preload headers DO NOT function "effectively the same" the same as HTTP/2 Push. Yes they have similar outcomes, no that does mean they function the same. They are related, but are not actually that similar except in the most trivial ways like using the word "Preload" - HTTP/2 Push: When the server thinks a client needs the resource, it pushes it into the client proactively, avoiding one round trip for the resource. The goal is to improve latency by sending the resource actively, independently of any DOM->render pipeline that would trigger the fetch. - Preload header: When the client requests a resource, the server delivers the page body, but it also tells it what it can load in parallel before parsing or JS eval. The goal is to improve latency by moving up the "fetch" stage, before the parse->DOM->render pipeline that would trigger the fetch. And beyond those two, over the past few years a new kid has appeared on the block: - 301 Early Hints: When the client requests a resource, the server sends a Preload hint telling it what to load before it even finishes generating the response. A 301 is delivered before the body is fully delivered, before even the first byte. The goal is to improve latency even further by moving the fetch stage up even earlier in the pipeline. Yes, they attack the same soft spot, but mechanically there is a VERY big difference between server-initialization and client-initialization, and between along-with-body and before-first-byte. (Obviously, 301s and Preloads are closer than anything.) Ignore the security stuff. The simplest reason HTTP/2 Push isn't so great is because it's not very good at accomplishing its goal. This is because browsers employ an ancient technique, originally written in hieroglyphs, called "caching", which means that the browser just won't request a resource if it already has it. A cache hit is the ultimate reduction in latency. But only the client browser knows what is in its cache, the server has no idea. With Push, you run a very real possibility of sending resources that aren't needed, overall losing efficiency. With 301s/preloads, you at worst receive a few wasted bytes from the useless headers. It's both much easier to get right, and much less costly if you get it wrong. It's also complicated to implement on top of all the other stuff. Preloads and 301s are vastly simpler and much more targeted additions to the HTTP stack, and HTTP is only useful insofar as implementations are compatible. So 301s/Preload are significantly easier to support and achieve much of the same purported benefits.

CodesInChaos 2y ago
"Early Hints" is 103. 301 is "moved permanently".

jauntywundrkind 2y ago

I find the excuse for unshipping especially ridiculous because developers never had a good chance to make use of Push! We can't see Pushes coming at us, cant be responsive to them! https://github.com/whatwg/fetch/issues/51 https://github.com/whatwg/fetch/issues/51 It also feels like the use case everyone was focusing on/acknowlegding of content delivery had plenty of opportunities left. There weren't very many visible public attempts! Very few people had access to libraries or starting places to begin to jump in, figure out what to Push!

_heimdall 2y ago

Well my understanding of the Push spec seems to have been as rusty as the spec itself. I forgot it was actually pushing full content that the server expects the client will need, I had it in my head that the request would just include a header that hints at dependencies similar to preload links in the <head>