Forum Discussion

erikkari_267307's avatar
erikkari_267307
Icon for Altostratus rankAltostratus
Jan 19, 2017

VS 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 verifie...
application delivery
BIG-IP
compression
devops
gzip
LTM
  • erikkari_267307's avatar
    erikkari_267307
    Jan 20, 2017

    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's avatar
IheartF5_45022
Icon for Nacreous rankNacreous
Jan 20, 2017

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

 

  • IheartF5_45022's avatar
    IheartF5_45022
    Icon for Nacreous rankNacreous
    Jan 20, 2017

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

     

  • erikkari_267307's avatar
    erikkari_267307
    Icon for Altostratus rankAltostratus
    Jan 20, 2017

    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' '' -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

     

    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

     

  • IheartF5_45022's avatar
    IheartF5_45022
    Icon for Nacreous rankNacreous
    Jan 20, 2017

    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.