> Le 22/12/2014 19:00, Lukas Tribus a écrit :
>>> OK, got it.
>>>
>>> What should I do with HAProxy to handle with them? (option
>>> accept-invalid-http-request is set already)
>>
>> You can't. HAproxy will not support those URI's.
>>
>> accept-invalid-http-request allows a limited set of forbidden
>> chars, but not the ones you are using (> 127/0x7f ASCII).
>
> That's not exactly true. When "accept-invalid-http-request" is used,
> haproxy accepts ASCII chars> 127, but will always capture them as bad
> messages.

Ah, thanks Cyril! I clearly misread the docs.



> From the "show errors" output I reput it here :
>> [22/Dec/2014:16:33:11.765] frontend https_frontend_ssl_terminate (#3):
>> invalid request
>> backend <NONE> (#-1), server <NONE> (#-1), event #7
>> src <example1>:49803, session #24184, session flags 0x00000080
>> HTTP msg state 27, msg flags 0x00000000, tx flags 0x00000000
>
> We can see "HTTP msg state 27", which means that haproxy has
> successfully passed the request parsing (27 = HTTP_MSG_BODY). Without
> "option accept-invalid-http-request", it would have failed on state 26
> (HTTP_MSG_ERROR)
>
> If Juriy is tracking 400 BADREQ requests, this is not the one provided
> previously.

Thanks for clarifying. Basically, in this particular situation we would have
to catch the request via tcpdump or we would need to be very lucky to
catch it with "show errors" on the unix admin socket, because it would be
filled with invalid but accepted requests like this one, hiding the request
that is actually not accepted ...



Lukas

                                          

Reply via email to