Nginx v1.11.5 Released | Hacker News Reader

Nginx v1.11.5 Released

nginx.org

111 pointsnikolay13 comments

    * Change: the --with-ipv6 configure option was removed, now IPv6
      support is configured automatically.

    * Change: now if there are no available servers in an upstream, nginx
      will not reset number of failures of all servers as it previously
      did, but will wait for fail_timeout to expire.

    * Feature: the ngx_stream_ssl_preread_module.

    * Feature: the "server" directive in the "upstream" context supports
      the "max_conns" parameter.

    * Feature: the --with-compat configure option.

    * Feature: "manager_files", "manager_threshold", and "manager_sleep"
      parameters of the "proxy_cache_path", "fastcgi_cache_path",
      "scgi_cache_path", and "uwsgi_cache_path" directives.

    * Bugfix: flags passed by the --with-ld-opt configure option were not
      used while building perl module.

    * Bugfix: in the "add_after_body" directive when used with the
      "sub_filter" directive.

    * Bugfix: in the $realip_remote_addr variable.

    * Bugfix: the "dav_access", "proxy_store_access",
      "fastcgi_store_access", "scgi_store_access", and "uwsgi_store_access"
      directives ignored permissions specified for user.

    * Bugfix: unix domain listen sockets might not be inherited during
      binary upgrade on Linux.

    * Bugfix: nginx returned the 400 response on requests with the "-"
      character in the HTTP method.

Is this the resolution we've all been waiting for regaring a longstanding issue many on HN have had with how nginx handles PUT/POST/DELETE on timeout?

    *) Change: now if there are no available servers in an upstream, nginx
       will not reset number of failures of all servers as it previously
       did, but will wait for fail_timeout to expire.

Reference to the huge HN post on the original issue: https://news.ycombinator.com/item?id=11217477

That was fixed 7 months ago.

https://trac.nginx.org/nginx/ticket/488#comment:4

(yes I realize this will be dead)

Checked out ngx_stream_ssl_preread_module but not sure about the use case.

Anyone?

I'm not totally sure, but it seems like it allows you to peek at the ClientHello message at the start of a TLS stream without performing a TLS handshake or otherwise interrupting the stream, so it can be forwarded with encryption to a backend server. For clients with Server Name Indication support (most of them,) the ClientHello message includes the unencrypted hostname of the server the client wants to connect to, so you could use it to route requests for different hosts to different internal servers in a virtual hosting/reverse proxy scenario (eg. requests for app1.com go to a different backend server than requests for app2.com) without Nginx having to decrypt the body of the requests at all.

It exposes a variable with the TLS SNI extension value for you to do stuff with in config:

http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_modul...

It's not clear from config whether you had to have already presented a valid certificate at that phase, though, or if it's just something you can use to check if it agrees with the Host header.

this is spot on

nginx is able to forward tcp streams without negotiating https or expecting http, from the docs it looks like this is for tcp streams only.

It has to be for TCP only because it can't do L7 balancing without terminating TLS.

You couldn't do this before? I thought it already had parity with haproxy in this respect.

Honest question, is there still a reason to use Nginx over HAProxy?

Nginx really is more of a swiss army knife web tool. It does a lot besides just load balancing and reverse proxying, and those things it definitely does better than HAProxy. AFAIK, you can't serve static assets with HAProxy, and HAProxy doesn't have any kind of caching built in, in addition to dozens of other features of Nginx that most people probably don't even know about.

In the HA load balancer category I think HAProxy is clearly a more capable tool since that's all it's supposed to do, but there's not really a simple answer to your question.

I think Nginx wins in perf and static hosting still right? And HAProxy wins in failover options.

Sadly, HAProxy doesn't have subrequests, e.g. X-Accel-Redirect feature.

Reply on news.ycombinator.com