VS in BigIP returns uncompressed HTTP response that was compressed by the backend Apache server

Question

Our backend servers run Apache and compress the HTTP data, however, it seems from the VIP associated to backend node is unpacking the compressed data and sending it out uncompressed. This was verified by executing curl: sending the request directly to the apache server returned compressed response while sending the same request to the corresponding VS resulted in the uncompressed response. Isn't the default behavior for VS to be in bypass mode (i.e. return response "as is")?&nbsp;
Checked the BigIP VS configuration; it has HTTP Profile = http and HTTP Compression Profile = None. There's no iRule associated with the VS.&nbsp;
What are we missing?&nbsp;

erikkari_267307 · Accepted Answer

That was it: Removed the html profile and now compression works through VS in F5 as well.&nbsp;
Thank you very much lheartF5 (sorry, can't see your actual name)!!! &nbsp;
Did try to up vote your answer but the button was disabled. Did it later. So it's all done. Thanks again.&nbsp;

erikkari_267307 · Answer

Just to clarify: VS = VIP in BigIP.&nbsp;

iheartf5_45022 · Answer

Can you show vs config?  Also the curl request/response headers for via the vs and direct to server?&nbsp;

iheartf5_45022 · Answer

Does your Apache config only have compression configured on one vHost and not the default?&nbsp;

erikkari_267307 · Answer

Thank you for replying. One important thing I forgot to mention is that our VS in F5 actually calls Varnish (cache server) which then calls Apache. Same deal though: calling Varnish returns compressed data (which is what we want) while calling VS in F5 with the same URI returns un-compressed data.&nbsp;
Below are the details ...&nbsp;
We have 2 Apache servers and both are configured for compression using mod_deflate.&nbsp;
Here's the VS configuration in F5 (taken from the SCF file):
    ltm virtual /Common/VS_NAME {
        destination /Common/VS_IP:VS_PORT
        ip-protocol tcp
        mask 255.255.255.255
        pool /Common/
        profiles {
            /Common/html { }
            /Common/http { }
            /Common/tcp { }
        }
        source 0.0.0.0/0
        source-address-translation {
            type automap
        }
        translate-address enabled
        translate-port enabled
    }&nbsp;
Here are request and response headers with curl:&nbsp;
1) Hitting VS. Notice there's no compression here since there's no "Content-Encoding: gzip" header:
curl -H 'Accept-Encoding: gzip' -H 'Accept: _/_' -H 'Accept-Language: en-us' -H 'Request-Id: 1'  '' -i
HTTP/1.1 200 OK
Date: Fri, 20 Jan 2017 04:14:31 GMT
Server: Apache-Coyote/1.1
Content-Type: application/json
Vary: Accept-Encoding
Content-Length: 4335
Cache-Control: public
Last-Modified: Fri, 20 Jan 2017 04:14:31 GMT
x-url: URI
x-host: VS_IP:VS_PORT
X-Varnish: 34381
Age: 0
Via: 1.1 varnish-v4
Access-Control-Allow-Origin: *
X-Cache: MISS
Accept-Ranges: bytes
Connection: Keep-Alive&nbsp;
2) Hitting Varnish. Notice compression took place which is indicated by the "Content-Encoding: gzip" header:
curl -H 'Accept-Encoding: gzip' -H 'Accept: _/_' -H 'Accept-Language: en-us' -H 'Request-Id: 1'  '' -i
HTTP/1.1 200 OK
Date: Fri, 20 Jan 2017 04:16:04 GMT
Server: Apache-Coyote/1.1
Content-Type: application/json
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: public
Last-Modified: Fri, 20 Jan 2017 04:16:04 GMT
x-url: URI
X-Varnish: 34427
Age: 0
Via: 1.1 varnish-v4
Access-Control-Allow-Origin: *
X-Cache: MISS
Accept-Ranges: bytes
Transfer-Encoding: chunked
Connection: keep-alive&nbsp;

iheartf5_45022 · Answer

Just guessing but perhaps the presence of the html profile is causing this. I assume the html profile causes content decompression (as cannot otherwise inspect it). So either remove the html profile, or add an http-compression profile.

Forum Discussion

VS in BigIP returns uncompressed HTTP response that was compressed by the backend Apache server

8 Replies

Recent Discussions

F5Access | MacOS Sonoma

Rewrite uri translation not working

Chrome V 124+ on MacOS - Virtual Server Access Issue

Transaction looks successful but file not downloading

Overwriting or adding LTM SSL Traffic cert and key using iControlREST

Related Content

Introduction of Incident Response

custom response page for api

F5 11.6.5.3 returns uncompressed HTTP response

FIX Message Response

F5 iRules for HTTP compression profile