BUG/MAJOR: compression/cache: Make it really works with these both filters
Caching the response with the compression enabled was totally broken. To fix the
problem, the compression must be done after caching the response. Otherwise it
needs to change the cache to store compressed and uncompressed objects for the
same ressource. So, because it is not possible for now, it is forbidden to
declare the compression filter before the cache one. To ease the configuration,
both can be implicitly declared (without "filter" keyword). The compression will
automatically be inserted after the cache.
Then, to make it works this way, the compression filter has been slighly
modified. Now, the response headers are updated after http-response rules
evaluations, instead of before. So, if the response contains a "Content-length"
header, it will be kept with the response stored in the cache. So this cached
response will be able to be served to clients not supporting the compression at
all.
diff --git a/doc/configuration.txt b/doc/configuration.txt
index d132223..9ff6755 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -17716,12 +17716,14 @@
The HTTP compression has been moved in a filter in HAProxy 1.7. "compression"
keyword must still be used to enable and configure the HTTP compression. And
-when no other filter is used, it is enough. But it is mandatory to explicitly
-use a filter line to enable the HTTP compression when two or more filters are
-used for the same listener/frontend/backend. This is important to know the
-filters evaluation order.
+when no other filter is used, it is enough. When used with the cache enabled,
+it is also enough. In this case, the compression is always done after the
+response is stored in the cache. But it is mandatory to explicitly use a filter
+line to enable the HTTP compression when at least one filter other than the
+cache is used for the same listener/frontend/backend. This is important to know
+the filters evaluation order.
-See also : "compression"
+See also : "compression" and section 9.4 about the cache filter.
9.3. Stream Processing Offload Engine (SPOE)
@@ -17767,12 +17769,14 @@
The cache uses a filter to store cacheable responses. The HTTP rules
"cache-store" and "cache-use" must be used to define how and when to use a
cache. By default the correpsonding filter is implicitly defined. And when no
-other filter than cache is used, it is enough. But it is mandatory to
-explicitly use a filter line to use a cache when two or more filters are used
-for the same listener/frontend/backend. This is important to know the filters
-evaluation order.
+other filters than cache or compression are used, it is enough. In such case,
+the compression filter is always evaluated after the cache filter. But it is
+mandatory to explicitly use a filter line to use a cache when at least one
+filter other than the compression is used for the same
+listener/frontend/backend. This is important to know the filters evaluation
+order.
-See also : section 10 about cache.
+See also : section 9.2 about the compression filter and section 10 about cache.
10. Cache
---------