Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx-1.14.0 stable version has been released

nginx.org

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Nginx-1.14.0 stable version has been released

#31

Post by Wingwing »

untog wrote: post #28
mariusmg wrote: post #21

Earlier quoted context omitted.

"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.

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.

That's a very Silicon Valley way to look at things. How much does that bandwidth cost on dial-up or 2G?

Re: Nginx-1.14.0 stable version has been released

#32

Post by brightball »

TechTeam12 wrote: post #7

>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?

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.

Re: Nginx-1.14.0 stable version has been released

#33

Post by blattimwind »

lazopm wrote: post #11
TechTeam12 wrote: post #7

>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?

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

Pretty much the same effect is granted to any HTTP version by simply including stylesheets or scripts verbatim into the HTML.

Re: Nginx-1.14.0 stable version has been released

#34

Post by niftich »

zzzcpan wrote: post #24
niftich wrote: post #19

Earlier quoted context omitted.

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…

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.

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/

Re: Nginx-1.14.0 stable version has been released

#35

Post by LinuxBender »

It appears that the default build does not check for libc support of Full RELRO and PIE. Are there any plans to add checks for this, or is it assumed that everyone sets the right CFLAGS and LDFLAGS? I know that Debian, Ubuntu, Gentoo, Alpine and Fedora package build specs do this by default today.

The reason I ask is that I see a lot of people build this themselves and run it from docker. I am concerned that they are not getting the various libc protections that should be enabled on internet facing daemons. i.e. stack-protector, fortify source, full relro, pie, ssp buffer limits, etc..

Re: Nginx-1.14.0 stable version has been released

#36

Post by tekromancr »

Wingwing wrote: post #31
untog wrote: post #28

Earlier quoted context omitted.

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.

That's a very Silicon Valley way to look at things. How much does that bandwidth cost on dial-up or 2G?

The client will kill the connection if it has the file cached, sooooo, not much.

Re: Nginx-1.14.0 stable version has been released

#37

Post by Piskvorrr »

blattimwind wrote: post #33
lazopm wrote: post #11

Earlier quoted context omitted.

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

Pretty much the same effect is granted to any HTTP version by simply including stylesheets or scripts verbatim into the HTML.

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.

Re: Nginx-1.14.0 stable version has been released

#38

Post by rakoo »

mariusmg wrote: post #21
cedricziel wrote: post #17

Earlier quoted context omitted.

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'…

"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.

That's the thing, it doesn't. HTTP2 Push is one of the big "open field" of HTTP2, and to know whether a document needs to be pushed will rely on good heuristics and black magic.

There is however a small standard that's emerging, pioneered by h2o, called casper (https://h2o.examp1e.net/configure/http2_directives.html#http...). The idea is that all resources ever sent to the client are stored in a probabilistic data structure in a cookie. On every request the structure is sent back to the server, which can then check whether the resource has good chances to be already known by the browser.

By the way there are some benchmarks done by h2o's author here: http://blog.kazuhooku.com/2015/10/performance-of-http2-push-.... The conclusion is all yours.

Re: Nginx-1.14.0 stable version has been released

#39

Post by [deleted] »

mariusmg wrote: post #21
cedricziel wrote: post #17

Earlier quoted context omitted.

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'…

"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.

[deleted]
Post reply on HN