On 19 July 2011 21:55, Willy Tarreau <w...@1wt.eu> wrote: > 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
Thanks Carlo & Willy. I am in agreement, this does seem like a very bad idea, I'll have to see if they can make a design change to prevent this from becoming a future headache. Graeme.