With Apache httpd 2.2, it was possible to setup a reverse proxy and use mod_deflate for compressing proxied content, honoring Accept-Encoding: gzip headers.
This configuration was sufficient for getting it to work:
LoadModule deflate_module modules/mod_deflate.so
LoadModule filter_module modules/mod_filter.so
SetOutputFilter DEFLATE
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
ProxyRequests Off
ProxyPass /tomcat http://localhost:8880/
ProxyPassReverse /tomcat http://localhost:8880/
ProxyPass /other http://localhost:8001/
ProxyPassReverse /other http://localhost:8001/
Now after upgrading to 2.4 (2.4.29 on Windows), that same configuration is accepted, and it indeed compresses static content served from DocumentRoot. But the same content is returned uncompressed, when retrieved via ProxyPass.
I know that I can configure Tomcat to do the compression, but there is also this other server that just ignores Accept-Encoding headers.
How can I set up a reverse proxy, and have proxied content compressed?
Edit:
Here are the headers returned, demonstrating that proxied content is not compressed by the 2.4 server:
----- Retrieving uncompressed from DocumentRoot ---------------------------------
C:\Temp>curl -I http://localhost/test.txt
HTTP/1.1 200 OK
Date: Tue, 09 Jan 2018 17:11:59 GMT
Server: Apache/2.4.29 (Win64) OpenSSL/1.1.0g
Last-Modified: Fri, 05 Jan 2018 12:58:40 GMT
ETag: "75441-5620701eb471c"
Accept-Ranges: bytes
Content-Length: 480321
Vary: Accept-Encoding
Content-Type: text/plain
----- The same from Tomcat ------------------------------------------------------
C:\Temp>curl -I http://localhost:8880/rr/test.txt
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"480321-1515157120042"
Last-Modified: Fri, 05 Jan 2018 12:58:40 GMT
Content-Type: text/plain
Content-Length: 480321
Date: Tue, 09 Jan 2018 17:11:59 GMT
----- 2.4.29: Retrieving compressed from DocumentRoot ---------------------------
C:\Temp>curl -I -H "Accept-Encoding: gzip" http://localhost/test.txt
HTTP/1.1 200 OK
Date: Tue, 09 Jan 2018 17:11:59 GMT
Server: Apache/2.4.29 (Win64) OpenSSL/1.1.0g
Last-Modified: Fri, 05 Jan 2018 12:58:40 GMT
ETag: "75441-5620701eb471c-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 48265
Content-Type: text/plain
----- 2.4.29: Not getting any compression for proxied Tomcat content ------------
C:\Temp>curl -I -H "Accept-Encoding: gzip" http://localhost/tomcat/rr/test.txt
HTTP/1.1 200 OK
Date: Tue, 09 Jan 2018 17:11:59 GMT
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"480321-1515157120042"
Last-Modified: Fri, 05 Jan 2018 12:58:40 GMT
Content-Type: text/plain
Content-Length: 480321
----- 2.2.14: Retrieving compressed from DocumentRoot ---------------------------
C:\Temp>curl -I -H "Accept-Encoding: gzip" http://localhost:81/test.txt
HTTP/1.1 200 OK
Date: Tue, 09 Jan 2018 17:11:59 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Fri, 05 Jan 2018 12:58:40 GMT
ETag: "90000000e7463-75441-5620701eb471c"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 48265
Content-Type: text/plain
----- 2.2.14: Proxied Tomcat content comes compressed ---------------------------
C:\Temp>curl -I -H "Accept-Encoding: gzip" http://localhost:81/tomcat/rr/test.txt
HTTP/1.1 200 OK
Date: Tue, 09 Jan 2018 17:11:59 GMT
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"480321-1515157120042"
Last-Modified: Fri, 05 Jan 2018 12:58:40 GMT
Content-Type: text/plain
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
All of this was tested on a plain 2.4.29 installation downloaded from ApacheHaus. The above configuration has been added to httpd.conf, nothing else has been changed. The same applies to the 2.2.14 installation (downloaded in 2009 from Apache), but that one was additionally changed to port 81.
I’ve managed to reproduce
curl+apache/tomcatbehavior that you describedThis is how I reproduced it (OS X El Capitan):
Tomcat:
Apache
Apache config (in its entirety):
Checking
As you can see, the output very closely matches your example
And here’s the fun part
If I use a regular GET request instead of HEAD (via browser or
curlwithout -I) tomcat’s response DOES GETS GZIPPEDNo idea why it’s happening though, looks like Apache’s + mod_proxy/defate misbehavior on HEAD requests. If you're saying it was OK in Apache 2.2 I would guess it might be somehow related to this adjustment
So I’d check whether the problem persists for GET requests in your case. If yes - provide even more details on your setup so that your environment could be 100% replicated - valid Dockerfile for apache and tomcat to isolate a likely environment discrepancy would be fine