Live data from Hacker News

Nginx-1.14.0 stable version has been released

nginx.org

51–60 of 68 posts

Re: Nginx-1.14.0 stable version has been released

#51
post #49
post #42

Earlier quoted context omitted.

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.

First you get a PUSH_PROMISE request that is a single frame. It's tiny. That tells the client what the server wants to send. The client can respond with a an RST_STREAM frame https://http2.github.io/http2-spec/#RST_STREAM Again, that's a single frame. By design it's meant to be extremely small and quick even on high latency, and/or low bandwidth connections.

You imply that there is a delay between the promise and the push, but it is not necessarily so. In fact the promise and the data may be sent in the same packet.

Re: Nginx-1.14.0 stable version has been released

#52
post #34
post #24

Earlier quoted context omitted.

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] an…

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

By "caching layer" he probably meant a proxy or load balancer level cache not the user agent cache. It would make total sense for a load balancer to statistically discover relationships.

Re: Nginx-1.14.0 stable version has been released

#53

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

The main problem with http2 push and why it’s pointless is that it’s not cache aware.

So you’re pushing unrequested data to everyone regardless.

h2o tries to solve this problem with a special cookie. More here:

http://blog.kazuhooku.com/2015/12/optimizing-performance-of-...

But without something like that it’s a feature that will never really gain traction.

Re: Nginx-1.14.0 stable version has been released

#56

Anyone with experience migrating a http service from nginx to Caddy or Træfik? Did it work out well or did you end up having to revert back to nginx? If so, what was missing? https://traefik.io/ https://caddyserver.com/

I only have one question, why?

I can understand picking one over the other start, but what motivation could you possibly have to actively ditch nginx altogether?

Re: Nginx-1.14.0 stable version has been released

#57

Anyone with experience migrating a http service from nginx to Caddy or Træfik? Did it work out well or did you end up having to revert back to nginx? If so, what was missing? https://traefik.io/ https://caddyserver.com/

Caddy's binary distribution is closed-license, so beware. If you need it to be truly free, compile it from source. I did like Caddy's simple configuration format, though.

Re: Nginx-1.14.0 stable version has been released

#58

Anyone with experience migrating a http service from nginx to Caddy or Træfik? Did it work out well or did you end up having to revert back to nginx? If so, what was missing? https://traefik.io/ https://caddyserver.com/

I only have one question, why? I can understand picking one over the other start, but what motivation could you possibly have to actively ditch nginx altogether?

Nginx struggles at basic stuff like load balancing to microservice backends because of trivial stuff like DNS caching when running inside container orchestration platforms

https://serverfault.com/questions/240476/how-to-force-nginx-...

With the new ingress in Kubernetes & lets encrypt plugin, you probably do not need nginx anymore, if you're adopting containers. In fact, it can be a hindrance to adopting container orchestration systems.

Re: Nginx-1.14.0 stable version has been released

#59

Earlier quoted context omitted.

I only have one question, why? I can understand picking one over the other start, but what motivation could you possibly have to actively ditch nginx altogether?

Nginx struggles at basic stuff like load balancing to microservice backends because of trivial stuff like DNS caching when running inside container orchestration platforms https://serverfault.com/questions/240476/how-to-force-nginx-... With the new ingress in Kubernetes & lets encrypt plugin, you probably do not need nginx anymore, if you're adopting containers. In fact, it can be a hindrance to adopting container or…

Sounds like it's more haproxy vs traefik or nginx vs Caddy.

If you don't need a Web server, you should probably be using haproxy already;)

Re: Nginx-1.14.0 stable version has been released

#60

Earlier quoted context omitted.

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.

I'm more concerned with a more "traditional" setup - say a festival providing WiFi to many people through limited upstream. Used to be, you could provide a caching proxy locally.

With the war on mitm, it's really hard to set up something that scales traffic in this way - even if the actual data requested by clients could readily scale.

I know it's a trade-off between security and features - but it still makes me sad.

Post reply on HN