Hi Alexey, On Thu, Sep 27, 2012 at 10:57:52PM +0400, Alexey Vlasov wrote: > Hi Willy Tarreau! > > On Tue, Sep 25, 2012 at 10:31:45PM +0200, Willy Tarreau wrote: > > > 00000 GET /phpinfo.php?PATH=/????????????? > > > 00034+ ?????/&&pid=42 HTTP/1.1 > > > ... > > > 00622 X-FORWARDED-URI: > > > /%D0%9A%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3/&pid=42 > > > 00691+ > > > > > > The full request should be like the following: > > > GET /phpinfo.php?PATH=/??????????????/&&pid=42 HTTP/1.1 > > > Even if those bytes don't display well in your terminal, they're > > definitely invalid. I'm surprized they were not encoded before > > being reported, I'll have to check why. However I suspect they're > > the sames as what appears in X-FORWARDED-REQUEST. If so, you'll > > note that the component which builds and emits those requests also > > does something strange with the double "&" when there was only one > > in the original request. > > Actually this request is not my fabrication, this is a request from my > client's site of our hosting. It worked everything perfectly untill I > update haproxy :) His site is based od such requests. > > I firstly said that i got Apache before haproxy, he sends requests in > not encoded.
I initially didn't understand that it was in this order, but this appears quite clear in your trace. The client behaves fine, it's apache which is re-encoding the request. I'll submit this issue on the HTTP working group so that we can decide whether such requests should be allowed to pass anyway or not, considering that we have a case of an existing one. I have tried to replay your request here, and indeed it is rejected. However, as soon as I add "option accept-invalid-http-request" either in the frontend or in the defaults section, it works flawlessly. Are you sure you added the proper directive and that you put it in the correct defaults section ? Regards, Willy
