On Thu, Aug 09, 2018 at 01:00:04PM -0400, Patrick Hemmer wrote:
> So I just noticed the behavior that when a request is queued and the
> client closes the connection, once a server slot frees up that request
> is still sent to the server which processes it and sends a response back.
> What's even more interesting is that the log indicates that everything
> was processed normally. It basically says the response was sent back to
> the client just fine.
>
> Example config:
> global
> stats socket /tmp/haproxy.sock level admin
> defaults
> log 127.0.0.1:1234 daemon
> mode http
> option httplog
> timeout queue 5s
> frontend f1
> bind :8001
> default_backend b1
> backend b1
> server s1 127.0.0.1:8081 maxconn 1
>
> Log output:
> <30>Aug 9 12:50:40 haproxy[12384]: 127.0.0.1:64723
> [09/Aug/2018:12:50:35.167] f1 b1/s1 0/0/0/5106/5106 200 118 - - ----
> 2/2/1/1/0 0/0 "GET /y HTTP/1.1"
> <30>Aug 9 12:50:45 haproxy[12384]: 127.0.0.1:64726
> [09/Aug/2018:12:50:35.526] f1 b1/s1 0/4749/0/5102/9851 200 118 - - ----
> 1/1/0/1/0 0/1 "GET /x HTTP/1.1"
>
> ^ In this, the server sleeps for 5 seconds, and then replies. I sent the
> request for /y, and then a request for /x, but killed the client on the
> /x request after 1 second. The request for /y was processed, but then so
> was the request for /x. The close flags ("----") indicate everything
> went fine.
Yes, and it's definitely intentional, so that scripts doing stuff like
echo -e "GET /check HTTP/1.1\r\nHost: bar\r\n\r\n" | nc 127.0.0.1 80
work properly. I've seen quite a bunch of these in monitoring scripts
over the years. Sometimes it's even more obvious as the response is
really not needed :
echo -e "GET /set-var?name=X&value=Y HTTP/1.0\r\n\r\n" > /dev/tcp/127.0.0.1/80
If you want to abort processing of a pending request when the client
closes, you simply need to add "option abortonclose". It's generally
recommended on public-facing configs. In this case you'll see something
like "CQ", "CC" or "CH" in the logs.
Regards
Willy
