25 ms·

In 2016, the Chromium team at Google produced a document [1] that examines usecases for HTTP/2 Push, talks about deployment models, and analyzes whether it's wo

In 2016, the Chromium team at Google produced a document [1] that examines usecases for HTTP/2 Push, talks about deployment models, and analyzes whether it's worth it. In this particular case, you'd push static content because you know it will be needed later, and this way the information arrives in the HTTP header instead of in the payload's content body, so by the time 'main.css' is needed, the UA's HTTP cache may already be populated with the file. That being said, I fail to see how in the general case, setting static headers in the server software's config for Push is useful [2][3], and wish that more implementations converged on a common way of describing what to push [4], so that tools could be built around discovering dependencies, and around interpreting that manifest to execute push. [1] https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0/edit?pref=2&pli=1 https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXj... [2] https://news.ycombinator.com/item?id=14077955#14081237 https://news.ycombinator.com/item?id=14077955#14081237 [3] https://news.ycombinator.com/item?id=12719563#12722383 https://news.ycombinator.com/item?id=12719563#12722383 [4] https://github.com/GoogleChromeLabs/http2-push-manifest https://github.com/GoogleChromeLabs/http2-push-manifest

wolfgang42 8y ago
Once you have a config setting, you've done all the work to actually get Push support, which is the hard part. Support for reading a manifest can be added later, or other people can write tools to read manifests and generate config files for the server.
zzzcpan 8y ago
Pushes are probably best implemented in a caching layer, not manually describing what to push. A web server should not just cache resources, but also learn what kind of resources are often requested with each page and just push those next time someone makes a request. And some sort of push prediction policy should be configurable.
- niftich 8y ago
  It's not sensible for pushes to be implemented in a caching layer, because pushes are effectively the manual overrides to the User-Agent's own caching; conversely, the User-Agent's cache is perfectly appropriate as a cache, and doesn't need HTTP/2 Push to work. HTTP/2 Push is effectively the server declaring they know better, so they prime the UA's cache to avoid additional roundtrips. Nginx does have a module [1] and a corresponding configuration option to scan outgoing headers for Link header preload directives, and once it has learned of a preload being declared by a resource, it will push that resource thereafter. Nginx talks about the justification for this feature, where they too admit that statically configuring pushes in the server config is not terribly useful -- it's quite often the wrong place to specify relationships between resources. [1] https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/ https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/
  - zzzcpan 8y ago
    If you can predict with high enough accuracy what resource is going to be requested by the client next, I don't see why pushing it would be a bad idea. Speculation is how we hide latency after all. And if you think about it, static pushes in general have very limited usefulness, almost non existent. Imagine when some url becomes popular and almost all of the requests to that url come from people who never visited the website before. It would make sense for a web server to learn what kind of resources clients request with that url and start pushing those resources to people ahead of time.
    - pas 8y ago
      For that it's easier to parse the pushed content. If it's HTML, then catch stlyesheets, JS, and some other static <img src=.../> things. It doesn't have to be flawless, after all it's just a speed-up. (And if you want a speed up write nice markup.) Similarly, it should be the backend behind the reverse-proxy that knows what's the page that has been just rendered, and knows about the user's session (is it brand new, or maybe it's not new, but still needs to push things because it's too old, and since then that particular page's background changed, etc.). And in case of an Angular/React/SPA thing, then the "bundler/compiler" should create a list of things to push for various URLs. Or the Angular/React team should talk with the Nginx team to figure out how to speed up things. (In case of SSR - server side rendering - the NodeJS server can emit the necessary Link headers, for example.)

wolfgang42 8y ago

Once you have a config setting, you've done all the work to actually get Push support, which is the hard part. Support for reading a manifest can be added later, or other people can write tools to read manifests and generate config files for the server.

zzzcpan 8y ago

Pushes are probably best implemented in a caching layer, not manually describing what to push. A web server should not just cache resources, but also learn what kind of resources are often requested with each page and just push those next time someone makes a request. And some sort of push prediction policy should be configurable.

niftich 8y ago
It's not sensible for pushes to be implemented in a caching layer, because pushes are effectively the manual overrides to the User-Agent's own caching; conversely, the User-Agent's cache is perfectly appropriate as a cache, and doesn't need HTTP/2 Push to work. HTTP/2 Push is effectively the server declaring they know better, so they prime the UA's cache to avoid additional roundtrips. Nginx does have a module [1] and a corresponding configuration option to scan outgoing headers for Link header preload directives, and once it has learned of a preload being declared by a resource, it will push that resource thereafter. Nginx talks about the justification for this feature, where they too admit that statically configuring pushes in the server config is not terribly useful -- it's quite often the wrong place to specify relationships between resources. [1] https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/ https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/
- zzzcpan 8y ago
  If you can predict with high enough accuracy what resource is going to be requested by the client next, I don't see why pushing it would be a bad idea. Speculation is how we hide latency after all. And if you think about it, static pushes in general have very limited usefulness, almost non existent. Imagine when some url becomes popular and almost all of the requests to that url come from people who never visited the website before. It would make sense for a web server to learn what kind of resources clients request with that url and start pushing those resources to people ahead of time.
  - pas 8y ago
    For that it's easier to parse the pushed content. If it's HTML, then catch stlyesheets, JS, and some other static <img src=.../> things. It doesn't have to be flawless, after all it's just a speed-up. (And if you want a speed up write nice markup.) Similarly, it should be the backend behind the reverse-proxy that knows what's the page that has been just rendered, and knows about the user's session (is it brand new, or maybe it's not new, but still needs to push things because it's too old, and since then that particular page's background changed, etc.). And in case of an Angular/React/SPA thing, then the "bundler/compiler" should create a list of things to push for various URLs. Or the Angular/React team should talk with the Nginx team to figure out how to speed up things. (In case of SSR - server side rendering - the NodeJS server can emit the necessary Link headers, for example.)