On Friday, September 30, 2016 12:02 AM Francis Daly wrote,
>> I've got an issue where nginx (see below for version/compile options)
>> returns a 405 (not allowed) to POST requests to clients when the upstream
>> proxy returns a 503.
> I don't see that, when I try to build a test system.
> Are yo
On Fri, Sep 30, 2016 at 09:56:50AM +, Jens Dueholm Christensen wrote:
> On Friday, September 30, 2016 12:02 AM Francis Daly wrote,
Hi there,
> >> I've got an issue where nginx (see below for version/compile options)
> >> returns a 405 (not allowed) to POST requests to clients when the upstrea
Hi!
Just use Brotli-compatible browser (Chrome, Firefox) and see headers of
the response in Developer tools.
It should say:
content-encoding: br
By the way: it only works for HTTPS.
30.09.2016 06:22, Dewangga Bachrul Alam пишет:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello!
Is th
> I'm not quite sure what the specific problem you are seeing is, from
> the previous mails.
>
> Do you have a reproducible test case where you can see the problem? (And
> therefore, see if any suggested fix makes a difference?)
>
> http://nginx.org/r/proxy_read_timeout should (I think) matter betw
Does anyone know why this is required for upstream keepalive?
- Grant
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
By default the Connection header is passed to the origin. If a client sends
a request with Connection: close, Nginx would send this to the upstream,
effectively disabling keepalive. By clearing this header, Nginx will not
send it on to the upstream source, leaving it to send its own Connection
head
> By default the Connection header is passed to the origin. If a client sends
> a request with Connection: close, Nginx would send this to the upstream,
> effectively disabling keepalive. By clearing this header, Nginx will not
> send it on to the upstream source, leaving it to send its own Connect
On Fri, Sep 30, 2016 at 9:24 AM, Grant wrote:
> > By default the Connection header is passed to the origin. If a client
> sends
> > a request with Connection: close, Nginx would send this to the upstream,
> > effectively disabling keepalive. By clearing this header, Nginx will not
> > send it on
FastCGI :
upstream fastcgi_backend {
server 127.0.0.1:9000;
keepalive 8;
}
server {
...
location /fastcgi/ {
fastcgi_pass fastcgi_backend;
fastcgi_keep_conn on;
...
}
}
Proxy :
upstream http_backend {
server 127.0.0.1:80;
keepalive 16;
}
se
A backend is a pool (upstream) for which work is distributed to, the pool
size has no bearing to keepalive.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,269997,27#msg-27
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.o
Thanks :)
I thought the more servers I have within my upstream location would mean I
should also increase my keepalive to suit for best performance etc.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,269997,270001#msg-270001
___
nginx mailin
I've been struggling with a very difficult to diagnose problem when
using apache2 and Odoo in a reverse proxy configuration with nginx.
Enabling keepalive for upstream in nginx seems to have fixed it. Why
is it not enabled upstream by default as it is downstream?
- Grant
12 matches
Mail list logo
