Hi Again, I hope I have been testing the right stuff thing; I changed my config to look like so: > http-send-name-header Host > option forwardfor > option http-server-close > option httpclose > option http-pretend-keepalive > […] > listen jiffy > bind *:8181 > # reqidel ^Host:
It won't work correctly if I remove the reqidel Host line; the POST uploads lead to: • Status Code:500 could not parse request Let me know if I should test different options. Michael Am 01.11.2012 um 15:03 schrieb Michael Seiferle <m...@basex.org>: > Hi Willy, > hi Cyril, > > (wow you are fast!) :-) > I will compile and try it as soon as I can, think I'll need two or three > hours though! > > Thanks! > Michael > Am 01.11.2012 um 14:53 schrieb Willy Tarreau <w...@1wt.eu>: > >> Hi Cyril, >> >> On Thu, Nov 01, 2012 at 02:25:17PM +0100, Cyril Bonté wrote: >>> OK, I could reproduce the issue, which happens as soon as >>> http-send-name-header is applied to a header provided in the request. >> >> This is interesting, because the same method is used when redispatching >> a request to another server after a failed connection attempt. I think >> that if I have not noticed it while testing, it is because all the >> servers I configured had the same name length. >> >>> I'm sending a patch just after this mail (for haproxy 1.4), but I'm not >>> sure it's the right way to fix it : after headers are removed, I >>> decrease the buf->send_max value with the length of headers removed. >> >> This makes sense indeed. >> >>> This bug doesn't appear as soon as reqdel is called on the same headers. >> >> And it explains why Michael experienced different behaviours when >> removing the header by hand or when using http-pretend-keep-alive >> which leaves headers intact. >> >> Michael, could you please try Cyril's patch and confirm that it completely >> fixes the issue you're experiencing ? If so, I'll merge it. >> >> Thanks, >> Willy >