Custom Query (2297 matches)
Results (34 - 36 of 2297)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#214 | fixed | Ability to detect presence of SNI header | ||
Description |
I think it would be a great feature to be able to detect the lack of the SNI header inside of a server block for an SSL listener. Something like: server {
} Could be the catch-all for all SSL requests hitting test.host.com that do include the headers needed for SNI to work (Windows XP + Internet Explorer 7/8). We could then display a page to the user that requests them to use a different browser or upgrade instead of them being served a possibly invalid or mismatching SSL certificate than the host they are trying to reach. |
|||
#1237 | fixed | ability to mirror traffic (like goreplay) without using post_action | ||
Description |
A lot of us want to mirror traffic from production setups to another server. This is NOT a/b testing - we dont want to split traffic. There's a lot of value in being able to apply production traffic to staging or when you are moving to a new architecture. Currently, the way to do this is via a specialized tool like goreplay (https://github.com/buger/goreplay https://goreplay.org) or using post_action in nginx - https://roshandawrani.wordpress.com/2016/09/23/can-nginx-mirror-the-http-request-on-multiple-destinations/ using post_action to mirror traffic is actually pretty popular on stackoverflow, but obviously it has its limitations (example only being able to support a single mirror, etc). It would be awesome if this could be built right into nginx as a proxy directive. For example, http://nginx.org/en/docs/http/ngx_http_upstream_module.html uses "backup" and "down" as two possible directives. One could also add "mirror" as a directive. This would mean that traffic would be sent to the mirror servers in addition to the normal servers... however, it would not wait for any response of the mirror (like proxy_ignore_client_abort). |
|||
#615 | fixed | Ability to specify different SSL certificate based on negotiated cipher suites and tls versions | ||
Description |
As TLS evolves, algorithms get deprecated and added the ability to selectively use certificates containing different types of keys based on which suite and TLS version are negotiated is useful. Apache supports this, google also does this in their custom server so that they can intelligently use the best and most appropriate key material. |