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

21–30 of 68 posts

Re: Nginx-1.14.0 stable version has been released

#21

Post by mariusmg »

cedricziel wrote: post #17
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?

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.

Re: Nginx-1.14.0 stable version has been released

#22

Post by wolfgang42 »

niftich wrote: post #19
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?

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…

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.

Re: Nginx-1.14.0 stable version has been released

#23

Post by dominotw »

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?

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

Re: Nginx-1.14.0 stable version has been released

#24

Post by zzzcpan »

niftich wrote: post #19
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?

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.

Re: Nginx-1.14.0 stable version has been released

#25

Post by andonisus »

gRpc support is amazing! I just wish this had been announced a week earlier, as I just spent a good amount of development time creating a service that subverts our NGINX server to create gRpc connections to desired microservices. It will be nice to just target the service by name directly instead of having to query Consul for their host IP addresses and ports.

Re: Nginx-1.14.0 stable version has been released

#27

Post by necro »

wolfgang42 wrote: post #20
necro wrote: post #15

Earlier quoted context omitted.

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?

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.

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 )

Re: Nginx-1.14.0 stable version has been released

#28

Post by untog »

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.

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.

Re: Nginx-1.14.0 stable version has been released

#29

Post by munjal116 »

sho wrote: post #16

gRPC support is very welcome! I've used gRPC internally but have felt a bit uncomfortable exposing a server directly to the internet for outside client use. Not to mention difficulties deploying in a downtime-free manner. gRPC + TLS in nginx will allow connections from outside that I'm comfortable with. Great improvement!

Agreed, added benefit -- much easier to expose gRPC services through Kubernetes Ingress.

Re: Nginx-1.14.0 stable version has been released

#30

Post by 0xFACEFEED »

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.

The server doesn't send the data every time. First it sends a data frame letting the client know "hey, I've got this thing if you need it" and the browser can respond with a frame saying "nah, don't need it".
Post reply on HN