On 10/20/12 11:49 PM, Willy Tarreau wrote:
Hello Dmitry,
On Sat, Oct 20, 2012 at 10:13:47PM +0400, Dmitry Sivachenko wrote:
Hello!
I am using haproxy-1.4.22.
Now I can see the last invalid request haproxy rejected with Bad Request
return code with the following command:
$ echo "show errors" | socat stdio unix-connect:/tmp/haproxy.stats
1) The request seems to be truncated at 16k boundary. With very large
GET requests I do not see the tail of URL string and (more important)
the following HTTP headers. I am running with tune.bufsize=32768. Is it
possible to tune haproxy to dump the whole request?
It always dumps the whole request. What you're describing is a request
too large to fit in a buffer. It is invalid by definition since haproxy
cannot parse it fully. If you absolutely need to pass that large a
request, you can increase tune.bufsize and limit tune.maxrewrite to
1024, it will be more than enough. But be careful, a website running
with that large requests will 1) not be accessible by everyone for the
same reason (some proxies will block the request) and 2) will be
extremely slow for users with a limited uplink or via 3G/GPRS.
As I wrote in my original e-mail, I use tune.bufsize=32768. I did not
tweak tune.maxrewrite though.
I will try to decrease maxrewrite to 1024 and see if 'show errors' will
dump more that 16k of URL.
I don't fully understand it's meaning though.
If I need to match up to 25k size requests using reqrep directive, will
tune.bufsize=32768 and tune.maxrewrite=1024 be enough for that?
I am aware of problems 1) and 2) but we have some special service here
at work which requires that large URLs.
2) The command above shows *the last* rejected request. In some cases
it complicates debugging, it would be convenient to see dumps of all
rejected requests for later analysis. Is it possible to enable logging
of these dumps to a file or syslog?
No, because haproxy does not access any file once started, and syslog
normally does not support messages larger than 1024 chars.
What is problematic with only the last request ? Can't you connect
more often to dump it ? There is an event number in the dump for that
exact purpose, that way you know if you have already seen it or not.
Problem is that you never know when next invalid request will arrive so
it is possible to miss one no matter how ofter you poll for new errors.
Since most request should fit even into 1024 buffer, would be nice to
dump at least first 1024 bytes via syslog for debugging.
