Forum Discussion
erikkari_267307
Altostratus
AltostratusVS in BigIP returns uncompressed HTTP response that was compressed by the backend Apache server
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")?
Checked the BigIP VS configuration; it has HTTP Profile = http and HTTP Compression Profile = None. There's no iRule associated with the VS.
What are we missing?
That was it: Removed the html profile and now compression works through VS in F5 as well.
Thank you very much lheartF5 (sorry, can't see your actual name)!!!
Did try to up vote your answer but the button was disabled. Did it later. So it's all done. Thanks again.
erikkari_267307Just to clarify: VS = VIP in BigIP.
IheartF5_45022Nacreous
Can you show vs config? Also the curl request/response headers for via the vs and direct to server?
- IheartF5_45022
Does your Apache config only have compression configured on one vHost and not the default?
- erikkari_267307
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.
Below are the details ...
We have 2 Apache servers and both are configured for compression using mod_deflate.
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 }
Here are request and response headers with curl:
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' '' -iHTTP/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
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' '' -iHTTP/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
- IheartF5_45022
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.
- erikkari_267307
That was it: Removed the html profile and now compression works through VS in F5 as well.
Thank you very much lheartF5 (sorry, can't see your actual name)!!!
Did try to up vote your answer but the button was disabled. Did it later. So it's all done. Thanks again.
- IheartF5_45022
No worries. You can really show your appreciation though by voting my answer as the accepted answer, not yours :-).
Vijay_ECirrus
Ha ha ;)