I know the $status variable shows you the upstream/origin's HTTP protocol
(e.g. HTTP/1.1 200) but is there a way to view the protocol the client made
the request with?
For example we've seen some S3 errors returned with a 505 which suggests
the user made a request with some strange HTTP protocol,
On Fri, Feb 10, 2017 at 10:38:36AM +, Mark McDonnell via nginx wrote:
Hi there,
> I know the $status variable shows you the upstream/origin's HTTP protocol
> (e.g. HTTP/1.1 200) but is there a way to view the protocol the client made
> the request with?
http://nginx.org/r/$server_protocol
o
Hello!
On Thu, Feb 09, 2017 at 05:49:13PM -0500, Paul Nickerson wrote:
> I've got the config below. I don't have these settings reconfigured
> anywhere else. My understanding is that no matter anything else at all
> anywhere else, and no matter whether the X-Forwarded-For field in the HTTP
> head
Hello!
On Fri, Feb 10, 2017 at 01:31:34PM +0800, linbo liao wrote:
> I setup an test Nginx 1.10.3 on local VM (Centos 6.7 x86_64). I configure
> the following location
>
> location =/404.html {
> root/usr/share/nginx/html;
> }
>
> As my understanding, it is not an valid url, but `nginx
On Fri, Feb 10, 2017 at 7:33 AM, Maxim Dounin wrote:
> And real_ip_recursive switched on means that this happens
> recursively. As a result, with the configuration in question
> nginx will use the first address in X-Forwarded-For provided, if
> any (assuming all addresses are valid).
> Note that "
Hello!
On Fri, Feb 10, 2017 at 10:20:01AM -0500, Paul Nickerson wrote:
> On Fri, Feb 10, 2017 at 7:33 AM, Maxim Dounin wrote:
> > And real_ip_recursive switched on means that this happens
> > recursively. As a result, with the configuration in question
> > nginx will use the first address in X-F
On Fri, Feb 10, 2017 at 11:05 AM, Maxim Dounin wrote:
> Note that my answer ("with the configuration in question nginx
> will use the first address in X-Forwarded-For provided") only
> applies to the particular configuration with "set_real_ip_from
> 0.0.0.0/0", and it is incorrect to assume it can
Hi Maxim,
Thanks for explaining why overloading ssl_protocols won't work. Since the
problem is with how OpenSSL works, will it work if we use other openssl
alternatives? I see people reporting boringssl and libressl work fine with
nginx. Does nginx still need to be modified to support overloading
We have json parsing data in between via api's. Anybody here to advise???
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,269577,272345#msg-272345
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
