On Fri, Jan 11, 2013 at 12:22:25PM +0000, William Lewis wrote: > Following up on this problem I had, thanks to the help of Baptiste and Willy > I've found a work around. > > It turns out that my web server (xlightweb) when compressing some responses > was truncating the data returned compared to size it was advertising. > > The slightly weird thing is that was was only causing a problem across a > network and not on the loopback device. The conclusion being this must be > related to timing somehow. > > Unfortunately I'm stuck with xlightweb, as much as I'd love to get rid of it, > but still need to make use of compression. > Haproxy to the rescue here with its relatively new ability to offload the > compression. > > This was the config I added. > > compression algo gzip > compression type text/cmd text/css text/csv text/html text/javascript > text/plain text/vcard text/xml application/json > application/x-www-form-urlencoded application/javascript > application/x-javascript > compression offload > > This will remove the Accepts-Encoding header from the request to your backend > and perform the compression in the haproxy itself where appropriate. > > The only final gottcha is make sure you are compiling haproxy with > USE_ZLIB=yes to enable gzip support > > Once again thanks to Baptiste and Willy for their help.
Thanks to you, Will, for bringing all the details here, it adds a lot of value to the list and will help other users of problematic gzip compressors find a workaround. Note that I wanted the offload option exactly for the same reason as you, as I have an old apache+mod_gzip which from time to time mangles a chunk, and I fixed it the same way. The compression code in haproxy is still young, but it's been a long time without any bug report on this, so I think it's safe now (and it's been used for several months on the haproxy web site now). Best regards, Willy
