On 06/01/2017 04:53 PM, Bernard McCormack wrote:
>
>
> After updating haproxy from 1.6.11 we saw a number of errors with the
> termination state “SD “ that
> is flooding our logs with errors. It seems to only occur on a random subset
> of requests. Attached
> is a pcap of failed request. I was wondering the if anyone else was seeing
> this? I’ve tried turning
> off gzip on the backend server but it seems to make no difference.
>
>
>
> The request all appear to be functioning correctly but it is generating a
> large number of log
> messages. The flow is browser -> nginx -> haproxy -> nginx.
>
>
>
> Jun 01 09:11:01 haproxy haproxy[10519]: haproxy haproxy[10519]:
> 127.0.0.1:24849
> [01/Jun/2017:09:11:01.190] MAINSITE_HTTP_MASTER phpmaster_80/webphpmaster01
> 0/0/0/790/790 200 19
>
> 22 - - SD-- 3/1/1/0/0 0/0 {CuQGKFkwEmU5eRCEAwZoAg==} "GET /favicon.ico
> HTTP/1.0"
> In the network capture, I didn't see the HTTP response header Content-Length, which could confuse haproxy and mark the connection as terminated from server side during data transfer as haproxy didn't know the actual size of response. I am assuming here that, haproxy reads the value of Content-Length and it will mark a request with SD if the server closes the connection, either by sending a FIN/ACK or RST, before haproxy has received the amount of data announced in Content-Length. My assumption could be wrong, so let's wait for some more experience people to answer your question. Last but not least, when you supply a network capture it is very useful to mention the system behind the IPs, in your case you have nginx-haproxy-nginx and I assumed that 1st HTTP response (frame 16) was from nginx to haproxy. The size of reassembled TCP payload also matches the response size mentioned in the log. Cheers, Pavlos
signature.asc
Description: OpenPGP digital signature
