Hi Cyril,

On Sat, Sep 06, 2014 at 02:35:27AM +0200, Cyril Bonté wrote:
> Hi Guillaume and Willy,
> 
> Le 05/09/2014 22:05, Cyril Bonté a écrit :
> >Indeed, I could reproduce the issue in 100% of my tests, sending 2
> >requests with keep-alive enabled.
> >
> >In case it helps to track the issue, I could simplify the configuration
> >up to :
> >   listen test :10002
> >     balance roundrobin
> >     mode http
> >     option http-server-close
> >     http-send-name-header Host
> >     server server-name 127.0.0.1:80
> >
> >then, to reproduce the issue :
> >$ echo -ne "GET / HTTP/1.1\r\nHost: test\r\n\r\nGET / HTTP/1.1\r\nHost:
> >test\r\n\r\n" | nc localhost 10002
> 
> I think we are in a similar case as the one I tried to fix in commit 
> 1ad838b678 [1].
> 
> I took some minutes to make some more tests and maybe I could come to a 
> fix for this new case, but I'm not sure it's enough and I would like to 
> definitely close issues on http-send-name-header in haproxy 1.4 ;-)
> 
> Willy, can you confirm that the patch attached is the only thing we need 
> ? In my previous tests, it solves the issue.

To be honnest, I think it is necessary, and I hope it will be enough. We
had this issue in 1.5-dev as well a long time ago and the problem was the
same, the beginning of the message was not moved. Now 1.5's buffer semantics
have changed to make all this much simpler. There is one thing to test to
confirm it's enough : make a farm with two untested servers, one which does
not respond and a valid one so that there's a retry and redispatch. Haproxy
will first pick server1, prepend the header, and try to send the request
there. After the failure it will redispatch to server2 and rewind the
buffer to change the header. On server2 you should see a valid request if
the fix is OK. That's how I managed to fix it in 1.5-dev. The config below
should be enough to reproduce it :

   listen test :10002
     balance roundrobin
     mode http
     option http-server-close
     http-send-name-header Host
     retries 1
     option redispatch
     server bad  127.0.0.1:12345
     server good 127.0.0.1:80

I also remember that rewinding POST requests is harder than rewinding
GET because the body was already partially parsed. I remember something
in 1.4 which we did to take care of that, either we refrain from parsing
the body before connecting when there's the send-name-header, or we could
correctly rewind. So sending a POST request through the config above will
tell you if that's OK :-)

Thanks for taking care of this Cyril,
Willy


Reply via email to