* 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.
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.
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.
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.
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.
13 comments
[ 18.9 ms ] story [ 108 ms ] threadAnyone?
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.
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.
https://trac.nginx.org/nginx/ticket/488#comment:4
(yes I realize this will be dead)
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.