Maxim,
Thanks for the detailed reply! In the organization I work for I see most
legacy backends support TLSv1 or support both TLSv1.1/1.2.
Since every backend that supports TLSv1.1 also supports TLSv1.2 (from my org
so far) I thought I was doing a small favor by leaving TLSv1.1 out of the
scope.
Hello All,
I found some strange behavior while troubleshooting a connectivity issue
today. Below was the scenario.
* Upstream Backend configured to allow TLSv1.1 and TLSv1.2
* Client (nginx) configured with proxy_ssl_protocols TLSv1 TLSv1.2
No matter the ordering of nginx proxy_ssl_protocols TL
Francis Daly Wrote:
---
> On Tue, May 24, 2016 at 11:10:31AM +0100, Andrew Hutchings wrote:
>
> Hi there,
>
> > As if by magic:
> http://nginx.org/en/docs/http/ngx_http_core_module.html#chunked_transf
> er_encoding
>
> Will that work here?
>
>
Hey Andrew,
Thanks for your reply. Actually we tried that already and still faced the
same issue. It can easily be reproduced; send any GET request with header
"transfer-encoding: chunked".
We tried the below already.
chunked_transfer_encoding off;
proxy_buffering off;
Posted at Nginx Forum:
We have a client sending a GET request who is also erroneously sending a
transfer-encoding : chunked Header.
This is causing nginx to wait for the client to send data before the client
finally times out. Is there anyway to tell nginx to ignore this header? We
have asked the client to get their a
Francis,
You are totally right! I forgot that that we were using some crap logic for
the variables; we are switching this to $request_method (the actual built in
variable). Your notes confirm to me what I was thinking all along: that the
client is likely closing the connection after 5 seconds. W
Hello!
Background
We've implemented a lightweight APIGW on nginx 1.9.9 using openresty
packages to customize the handling/proxying logic. We have dozens clients
that are able to leverage this implementation just fine.
The Issue
We have one client that is experiencing some weird issues when try
