On 24.11.2012 18:25, Willy Tarreau wrote:
Hi Dmitry,
On Thu, Nov 22, 2012 at 08:03:26PM +0400, Dmitry Sivachenko wrote:
Hello!
I was reading docs about HTTP compression support in -dev13 and it is a bit
unclear to me how it works.
Imagine I have:
compression algo gzip
compression type text/html text/javascript text/xml text/plain
in defaults section.
What will haproxy do if:
1) backend server does NOT support compression;
Haproxy will compress the matching responses.
2) backend server does support compression;
You have two possibilities :
- either you just have the lines above, and the server will see
the Accept-Encoding header from the client and will compress
the response ; in this case, haproxy will see the compressed
response and will not compress again ;
- or you also have a compression offload line. In this case,
haproxy will remove the Accept-Encoding header before passing
the request to the server. The server will then *not* compress,
and haproxy will compress the response. This is what I'm doing
at home because the compressing server is bogus and sometimes
emits wrong chunked encoded data!
3) backend server does support compression and there is no these two
compression* lines in haproxy config.
Then haproxy's normal behaviour remains unchanged, the server compresses
if it wants to and haproxy transfers the response unmodified.
I think documentation needs to clarify things a bit.
Possibly, however I don't know what to clarify nor how, it's always
difficult to guess how people will understand a doc :-(
Could you please propose some changes ? I would be happy to improve
the doc if it helps people understand it.
Thank you very much for the explanation.
Please consider the attached patch, I hope it will clarify haproxy's behavior a
bit.
--- configuration.txt.orig 2012-11-26 06:11:05.0 +0400
+++ configuration.txt 2012-11-28 17:45:25.0 +0400
@@ -1903,16 +1903,23 @@
Compression will be activated depending on the Accept-Encoding request
header. With identity, it does not take care of that header.
+ If backend servers support HTTP compression, these directives
+ will be no-op: haproxy will see the compressed response and will not
+ compress again. If backend servers do not support HTTP compression and
+ there is Accept-Encoding header in request, haproxy will compress the
+ matching response.
The offload setting makes haproxy remove the Accept-Encoding header to
prevent backend servers from compressing responses. It is strongly
recommended not to do this because this means that all the compression work
will be done on the single point where haproxy is located. However in some
deployment scenarios, haproxy may be installed in front of a buggy gateway
- and need to prevent it from emitting invalid payloads. In this case, simply
- removing the header in the configuration does not work because it applies
- before the header is parsed, so that prevents haproxy from compressing. The
- offload setting should then be used for such scenarios.
+ with broken HTTP compression implementation which can't be turned off.
+ In that case haproxy can be used to prevent that gateway from emitting
+ invalid payloads. In this case, simply removing the header in the
+ configuration does not work because it applies before the header is parsed,
+ so that prevents haproxy from compressing. The offload setting should
+ then be used for such scenarios.
Compression is disabled when:
* the server is not HTTP/1.1.
