We are getting an awful lot of 400 responses being sent back to our
clients.
For example, consider these two, first one resultsed in a 400, where as
the second one didn’t.
79.a.c.d - - [04/Jul/2008:13:14:21 +0000] GET /sportbladet/?service=rss
HTTP/1.1 “400” 173 “-” “Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4;
en-US; rv:1.9) Gecko/2008061004 Firefox/3.0” “-”
79.a.c.d - - [04/Jul/2008:13:14:22 +0000] GET /sportbladet/?service=rss
HTTP/1.1 “200” 18003 “-” “Mozilla/5.0 (Macintosh; U; Intel Mac OS X
10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0” “-”
We are using nginx as a frontend loadbalancer, but our code does not
generate 400 errors. So under what circumstances would nginx return a
400 request?
Thanks
a
On Fri, Jul 04, 2008 at 02:23:46PM +0100, Alan W. wrote:
HTTP/1.1 “200” 18003 “-” “Mozilla/5.0 (Macintosh; U; Intel Mac OS X
10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0” “-”
We are using nginx as a frontend loadbalancer, but our code does not
generate 400 errors. So under what circumstances would nginx return a
400 request?
Reasons of these errors are logged at info level in error_log:
error_log /path/to/log info;
We are using nginx as a frontend loadbalancer, but our code does not
generate 400 errors. So under what circumstances would nginx return a
400 request?
Reasons of these errors are logged at info level in error_log:
error_log /path/to/log info;
Thanks Igor — i take it “info” isn’t the default? because we have
nothing in that log file thus far.
We are using nginx as a frontend loadbalancer, but our code does not
generate 400 errors. So under what circumstances would nginx return a
400 request?
Reasons of these errors are logged at info level in error_log:
error_log /path/to/log info;
Thanks Igor — i take it “info” isn’t the default? because we have
nothing in that log file thus far.
On Fri, Jul 04, 2008 at 03:50:47PM +0100, Alan W. wrote:
We are using nginx as a frontend loadbalancer, but our code does not
generate 400 errors. So under what circumstances would nginx return a
400 request?
Reasons of these errors are logged at info level in error_log:
error_log /path/to/log info;
Thanks Igor — i take it “info” isn’t the default? because we have
nothing in that log file thus far.
The default level is notice.
Unimportant client errors are logged at info level.
interesting, i had to restart the service here to get this logging
enabled; a simply HUP didn’t work.
okay, back to this though – what makes nginx throw a 400 response?
in the error log i get lots of these:
2008/07/14 08:22:09 [info] 9392#0: *54478 client 91.149.53.139 closed
keepalive connection
2008/07/14 08:22:09 [info] 9391#0: *55972 client 193.252.122.88 closed
keepalive connection
2008/07/14 08:22:09 [info] 9391#0: *55981 client 88.191.15.62 closed
keepalive connection
some of these:
2008/07/14 08:22:10 [warn] 9392#0: *56100 an upstream response is
buffered to a temporary file /usr/local/nginx/proxy_temp/1/35/0000000351
while reading upstream, client: 87.122.18.68, server:
rss.feedsportal.com, request: “GET /c/269/f/3544/index.rss HTTP/1.1”, u
very few of these:
2008/07/14 08:23:53 [info] 9392#0: *105147 client timed out (110:
Connection timed out) while reading client request line, client:
213.186.114.166, server: 0.0.0.0:80
Yet we get TONS of 400’s being reported in the access logs.
What happens if a backend isn’t able to process a connection? Does
nginx not through a 503 instead?