4 ms·

>http2_push /static/css/main.css; Silly question, but what's the use case for the HTTP/2 Push? Their example with pushing doesn't make sense to me. Why would y

>http2_push /static/css/main.css; Silly question, but what's the use case for the HTTP/2 Push? Their example with pushing doesn't make sense to me. Why would you want to push static content?

libre-man 8y ago
So that the files can be downloaded before the html is parsed if I recall correctly.
- deleted 8y ago
  [deleted]
wincent 8y ago
You push it along with the initial page, before the browser has even requested it.
lazopm 8y ago
It's a way to preemptively send assets to the client before they request them.
- blattimwind 8y ago
  Pretty much the same effect is granted to any HTTP version by simply including stylesheets or scripts verbatim into the HTML.
  - Piskvorrr 8y ago
    That's anything but "simple" - you might want to reuse those stylesheets/scripts on other pages as well, for example; if you inline them into HTML, you're now wasting far more bandwidth, as you're unconditionally pushing them with every HTML response.
kijin 8y ago
That command probably goes in a "location" block that matches the set of HTML pages that use main.css. Normally, the browser parses HTML, finds a <link> tag that mentions main.css, and then requests main.css. With HTTP/2 push, by the time the browser has finished parsing the <link> tag, main.css has already been delivered. If the browser already has main.css in its cache, it can reject the push.
wolfgang42 8y ago
Let's say you have an HTML page which links to main.css. Ordinarily, the request goes: Client: GET /index.html Server: <index.html> Client (after parsing): GET /main.css Server: <main.css> Loading the page thus takes 2 round trips, one for the main page and one for the content. (Or more, if you have e. g. includes in the CSS.) Here's what it would look like with HTTP/2 Push: Client: GET /index.html Server: <index.html>, <main.css> (PUSH) This only takes 1 round trip; since the server knows that main.css will be required shortly it can preemptively send it. In particular, this might offer a significant speedup for high-latency connections; it also theoretically reduces the need for bundling tools since you can have the server just push all of the individual files. The obvious problem with this scheme is that if the client already has main.css then it's a waste of bandwidth to send it again. The client can cancel the push, but by the time it finds out about it a bunch of data has already been sent. There is a proposal for 'Cache Digests' which will allow the client to send a Bloom filter of its cache so the server can tell whether or not it has the file already, but as far as I'm aware no major client or server has implemented this yet.
necro 8y ago
If you agree that using a CDN for static content is a good idea, then it would seem HTTP/2 Push is useless. The website is served from your servers while the static content is served from a CDN so you can't "push" it in the same stream as you webpage content. Am I missing something here?
- wolfgang42 8y ago
  Yes, you can't push cross-origin.[1] However, there's still a lot of use-cases where this is useful, such as if your entire site is static content, or if your app servers are behind the CDN as well. [1]: Yet. I believe the web packaging standard (intended, among other things, to replace AMP) allows pushing bundles signed by other origins.
  - necro 8y ago
    So there are 3 basic cases that websites use: 1. Site and static content are served directly by your webserver. ( HTTP2/push helpful ) 2. Site served by your web servers but static content is served by a CDN ( HTTP2/push NOT helpful ) 3. Site and static content proxied by some service. ( HTTP2/push helpful )
cedricziel 8y ago
I think there's a common misconception with the term "push". HTTP2 doesn't push in terms of a push notification, but rather "pushes" assets down the connection that are known to be needed by the currently transferred document (whatever that may be). That way, the web server can pro-actively push the named stylesheet to the client as it knows that the stylesheet is needed to render the page. That way the client doesn't have to ask the server (which would result in a new roundtrip).
- mariusmg 8y ago
  "that are known to be needed by the currently transferred document" How does the server knows what the browser/client "needs" ? The client can have the cached stylesheet already. Making the server "in control" seems wrong and make things even more complicated.
  - untog 8y ago
    The client can cancel the push. But yes, there's definitely wasted bandwidth here - the reason to still do it is that connections are now fast enough that the extra download time is small compared to the time required to parse HTML/send new HTTP request/receive response/render CSS.
    - Wingwing 8y ago
      That's a very Silicon Valley way to look at things. How much does that bandwidth cost on dial-up or 2G?
      - tekromancr 8y ago
        The client will kill the connection if it has the file cached, sooooo, not much.
        rakoo 8y ago
        It's 2G. By the time the cancel is received by the server, the server will have sent the resource, the bytes will have traveled and the user will be billed.
niftich 8y ago
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/
dominotw 8y ago
you guess what the page might need and 'push' the contents down so that the page loads faster.
brightball 8y ago
Basically to change this... - Request index.html - Parse index.html - Request .js and .css and .jpg/png, etc found inside - Parse .js and .css found inside - Request additional .js, .css and .jpg/png, etc found within js/css - Parse.... Into this... - Request index.html, .css, .js, *.jpg/png - Parse all To avoid multiple round trips and improve initial page load time if you "know" what's going to be requested from the beginning.

>http2_push /static/css/main.css; Silly question, but what's the use case for the HTTP/2 Push? Their example with pushing doesn't make sense to me. Why would you want to push static content?

libre-man 8y ago

So that the files can be downloaded before the html is parsed if I recall correctly.

deleted 8y ago
[deleted]

wincent 8y ago

You push it along with the initial page, before the browser has even requested it.

lazopm 8y ago

It's a way to preemptively send assets to the client before they request them.

blattimwind 8y ago
Pretty much the same effect is granted to any HTTP version by simply including stylesheets or scripts verbatim into the HTML.
- Piskvorrr 8y ago
  That's anything but "simple" - you might want to reuse those stylesheets/scripts on other pages as well, for example; if you inline them into HTML, you're now wasting far more bandwidth, as you're unconditionally pushing them with every HTML response.

kijin 8y ago

That command probably goes in a "location" block that matches the set of HTML pages that use main.css. Normally, the browser parses HTML, finds a <link> tag that mentions main.css, and then requests main.css. With HTTP/2 push, by the time the browser has finished parsing the <link> tag, main.css has already been delivered. If the browser already has main.css in its cache, it can reject the push.

wolfgang42 8y ago

Let's say you have an HTML page which links to main.css. Ordinarily, the request goes: Client: GET /index.html Server: <index.html> Client (after parsing): GET /main.css Server: <main.css> Loading the page thus takes 2 round trips, one for the main page and one for the content. (Or more, if you have e. g. includes in the CSS.) Here's what it would look like with HTTP/2 Push: Client: GET /index.html Server: <index.html>, <main.css> (PUSH) This only takes 1 round trip; since the server knows that main.css will be required shortly it can preemptively send it. In particular, this might offer a significant speedup for high-latency connections; it also theoretically reduces the need for bundling tools since you can have the server just push all of the individual files. The obvious problem with this scheme is that if the client already has main.css then it's a waste of bandwidth to send it again. The client can cancel the push, but by the time it finds out about it a bunch of data has already been sent. There is a proposal for 'Cache Digests' which will allow the client to send a Bloom filter of its cache so the server can tell whether or not it has the file already, but as far as I'm aware no major client or server has implemented this yet.

necro 8y ago

If you agree that using a CDN for static content is a good idea, then it would seem HTTP/2 Push is useless. The website is served from your servers while the static content is served from a CDN so you can't "push" it in the same stream as you webpage content. Am I missing something here?

wolfgang42 8y ago
Yes, you can't push cross-origin.[1] However, there's still a lot of use-cases where this is useful, such as if your entire site is static content, or if your app servers are behind the CDN as well. [1]: Yet. I believe the web packaging standard (intended, among other things, to replace AMP) allows pushing bundles signed by other origins.
- necro 8y ago
  So there are 3 basic cases that websites use: 1. Site and static content are served directly by your webserver. ( HTTP2/push helpful ) 2. Site served by your web servers but static content is served by a CDN ( HTTP2/push NOT helpful ) 3. Site and static content proxied by some service. ( HTTP2/push helpful )

cedricziel 8y ago

I think there's a common misconception with the term "push". HTTP2 doesn't push in terms of a push notification, but rather "pushes" assets down the connection that are known to be needed by the currently transferred document (whatever that may be). That way, the web server can pro-actively push the named stylesheet to the client as it knows that the stylesheet is needed to render the page. That way the client doesn't have to ask the server (which would result in a new roundtrip).

mariusmg 8y ago
"that are known to be needed by the currently transferred document" How does the server knows what the browser/client "needs" ? The client can have the cached stylesheet already. Making the server "in control" seems wrong and make things even more complicated.
- untog 8y ago
  The client can cancel the push. But yes, there's definitely wasted bandwidth here - the reason to still do it is that connections are now fast enough that the extra download time is small compared to the time required to parse HTML/send new HTTP request/receive response/render CSS.
  - Wingwing 8y ago
    That's a very Silicon Valley way to look at things. How much does that bandwidth cost on dial-up or 2G?
    - tekromancr 8y ago
      The client will kill the connection if it has the file cached, sooooo, not much.
      - rakoo 8y ago
        It's 2G. By the time the cancel is received by the server, the server will have sent the resource, the bytes will have traveled and the user will be billed.

niftich 8y ago

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/

dominotw 8y ago

you guess what the page might need and 'push' the contents down so that the page loads faster.

brightball 8y ago

Basically to change this... - Request index.html - Parse index.html - Request .js and .css and .jpg/png, etc found inside - Parse .js and .css found inside - Request additional .js, .css and .jpg/png, etc found within js/css - Parse.... Into this... - Request index.html, .css, .js, *.jpg/png - Parse all To avoid multiple round trips and improve initial page load time if you "know" what's going to be requested from the beginning.