Re: nginx 400 status code sometimes reported as 502 in haproxy

2009/7/9 Willy Tarreau <w#1wt.eu>:
>
> On Mon, Jul 06, 2009 at 12:31:07PM +0200, Jean-Baptiste Quenot wrote:
>> Hi there,
>>
>> In my setup an incoming HTTP requests follows the chain Varnish ->
>> Haproxy -> Nginx.  Haproxy is configured to have Nginx as one of the
>> backends.
>> I have an interesting problem: some client browsers have a too big
>> cookie in the request header, and Nginx is thus issuing a 400 Bad
>> Request.  As a result, this 400 error code is propagated to Haproxy in
>> most cases, but in some occasions Haproxy reports a 502 Bad Gateway.
>> In the attached Haproxy log output, haproxy reports mostly 400 errors,
>> but in some cases it is reporting 502, whereas Nginx always reports
>> 400.
>>
>> It's a bit annoying for me, since I carefully monitor all 5xx status
>> codes, as it usually means there is something wrong on the server
>> side.
>>
>> I'm using haproxy 1.3.15.9 on Ubuntu 9.04
>>
>> Any idea?
>
> As you can see, you get the flags "SH--" with a 502, which means that
> the server unexpectedly closed the connection before sending all the
> headers. It might be possible that a close happens too fast after an
> error 400, and that the server is configured with SO_LINGER=0, which
> means that the response can sometimes be dropped from the network buffers
> before reaching the client (haproxy here).
>
> Using haproxy 1.3.18 + socat, you could connect to the stats socket and
> issue a "show errors" command, which would report the exact copy of the
> last failed response, with pointers to the first invalid character. This
> can help a lot sometimes.

Hi Willy,

I'm successfully using the stats socket for monitoring. But when I did a "show errors" nothing was printed at all. I tried using socat with "show stat" and it works, but "show errors" after getting a 502" never prints anything.

Otherwise you suggest that Nginx is closing the connection too fast. I checked this, and SO_LINGER is only used for a timed out connection, but there is no timeout involved here AFAICT.

-- 
Jean-Baptiste Quenot
http://jbq.caraldi.com/