Hi Patrick,
> With 1.5-dev22, we have a scenario where haproxy is saying the client
> closed the connection, but really the server is the one that closed it.
>
> Here is the log entry from haproxy:
> haproxy[12540]: 10.230.0.195:33580 storage_upd
> storage_upd/storage_upd_2 0/0/0/522/555 0/0/0/0/0 0/0 412/271 200 CD--
> 73E3-20FF5 + GET /1/public_link/1BMcSfqg3OM4Ng HTTP/1.1
>
> The log format is defined as:
> capture request header X-Request-Id len 64
> log-format %ci:%cp\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\
> %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %U/%B\ %ST\ %tsc\ %hrl\ +\ %r
>
> Attached is the haproxy config, along with a packet capture between
> haproxy and the backend server.
> The packet capture shows that the backend server listening on port 4001
> sent a TCP FIN packet to haproxy first. Therefore haproxy shouldn't
> have logged it with "C---"
I tried to reproduce this with your config and a bogus backend, which
closes the connection after the following response header (no content):
HTTP/1.1 200 OK
Date: Fri, 18 Apr 2014 21:25:22 GMT
Server: Apache/2.4.2 (Win32) OpenSSL/1.0.1c PHP/5.4.4
X-Powered-By: PHP/5.4.4
Content-Length: 18
Connection: close
Content-Type: text/html
(exactly what your backend did), but for me, haproxy correctly logs SD:
haproxy[4887]: 10.0.0.3:49365 storage_upd storage_upd/storage_upd_1 \
9/0/1/3/14 0/0/0/0/0 0/0 102/200 200 SD-- - + GET \
/test-bogus-content-length.php HTTP/1.1
I don't understand the difference in our setups. Are you able to reliably
reproduce this? Could you capture both the frontend and the backend session
in a single pcap?
Regards,
Lukas
