NetScaler Compression not working for the Load Balanced Traffic.

NetScaler Compression not working for the Load Balanced Traffic.

book

Article ID: CTX220664

calendar_today

Updated On:

Description

Compression policy is not working as expected for JavaScript, when AppFirewall is turned on.

Resolution

Workaround:
Please change the Cache-Control header to not include no-transform directive by using the below link.
http://httpd.apache.org/docs/2.0/mod/mod_headers.html
 
Example: Header set Cache-Control “public”

Problem Cause

Summary:
 
There are few Modules in Netscaler(Appflow, Appfw) which need Uncompressed Responses hence we either Delete or Corrupt Accept-Encoding header coming from the Client and Add “Accept-Encoding: identity”. The AppFw needs to see the data uncompressed as it does response side parsing of HTML, XML, JavaScript, CSS etc.
 
If Netscaler receives a compressed data then it has to first decompress the data, perform the inspection and then compress the data, this adds to a lot of processing overhead on Netscaler. To avoid the overhead of processing, we disable compression on the request side so the AppFw module can inspect and Compress the data.
 
Now Coming to the problem of not compressing the data in this case is because of the presence of “Cache-Control: public, no-transform” directive which according to RFC2616 dictates not to transform the response-entity as explained below.
 
14.9.5 No-Transform Directive
 
   no-transform
      Implementors of intermediate caches (proxies) have found it useful
      to convert the media type of certain entity bodies. A non-
      transparent proxy might, for example, convert between image
      formats in order to save cache space or to reduce the amount of
      traffic on a slow link.
 
      Serious operational problems occur, however, when these
      transformations are applied to entity bodies intended for certain
      kinds of applications. For example, applications for medical
      imaging, scientific data analysis and those using end-to-end
      authentication, all depend on receiving an entity body that is bit
      for bit identical to the original entity-body.
 
      Therefore, if a message includes the no-transform directive, an
      intermediate cache or proxy MUST NOT change those headers that are
      listed in section 13.5.2 as being subject to the no-transform
      directive. This implies that the cache or proxy MUST NOT change
      any aspect of the entity-body that is specified by these headers,
      including the value of the entity-body itself.


Analysis:
GET /assets/js/extra/jquery-1.10.2.js HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_2 like Mac OS X) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0 Mobile/14C92 Safari/602.1
Accept-Language: en-gb
Referer: http://www.abc.com/string/204-32/result
True-Client-IP: 203.x.x.x
Pragma: no-cache
Akamai-Device: smartphone
X-Akamai-CONFIG-LOG-DETAIL: true
TE:  chunked;q=1.0
Connection: TE
Akamai-Origin-Hop: 2
Via: 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 akamai.net(ghost) (AkamaiGHost)
X-Forwarded-For: 203.x.x.x, 125.x.x.x
Host: www.abc.com
Cache-Control: no-cache, max-age=0
Connection: keep-alive
X-forwarded-for: 173.x.x.x 
Accept-Encoding: identity
 
HTTP/1.1 200 OK
Date: Tue, 31 Jan 2017 09:00:29 GMT
Server: Apache
Accept-Ranges: bytes
Content-Length: 93104
Vary: Accept-Encoding
Cache-Control: public, no-transform             // Because of the presence of no-transform we bypass compression though we hit the policy for compression.
Expires: Thu, 02 Mar 2017 09:00:29 GMT
Connection: close
Content-Type: application/javascript


 

Additional Information

http://httpd.apache.org/docs/2.0/mod/mod_headers.html