On Tue, Jul 19, 2011 at 11:06:58AM -0700, carlo wrote: > Check out tune.bufsize and tune.maxrewrite in the Performance Tuning section > of the HAProxy docs.
Indeed. I would add something : an application which generates headers or URLs that are *that* long will never reliably work over the internet and will experience trouble through a number of components. For instance, Apache limits each line to 8192 bytes, very close to your header's length, and Apache is present everywhere. Also, the client will have to repost this request, making it even longer. BTW, if the page you're pointing to contains images, all of them will be fetched with a Referer containing that long URL. This is a very bad idea again. Imagine if the page contains 50 objects (css, js, images, ...), then the browser has to upload 51 times 8 kB or half a megabyte. This can take a huge time in many environments (ADSL, 3G, ...). All this really translates a bad initial design which should be fixed one way or another. Last, I invite you to read suggestions from the HTTP spec here : http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-3.2 "Various ad-hoc limitations on header length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets." You're more than twice the recommended size, you're asking for trouble. In haproxy, to workaround the default limit, you can increase tune.bufsize and decrease tune.maxrewrite. I'm used to set them to 8kB and 1kB respectively because that's fine everywhere. You can set maxrewrite to 1kB and bufsize to 16kB to see if that fixes your issue, but I really invite you to fix the application before it's too late ! Regards, Willy
