Compression iRules - GZIP vs. Deflate Preference

bl0ndie beat me to it (and finally when I knew an answer to an iRule question!)

 

 

Per the TCL documentation at (Click here) semi-colons and newlines are command separators. So, if you need to include multiple commands on a single line, use a semi-colon to separate them. In the example by unRuleY, "event disable" is a separate command and needs to be delimited as such.

 

 

As a side note, I did find a couple of good references for TCL in case you are interested.

 

 

Click here for Tcl Reference Manual

 

Click here for Tcl for Web Nerds

 

 

-Joe

Thanks guys that took and my compression stats are now incrementing.

 

 

Time for Beer 2 today! Many thanks.

 

 

-t

Doh, I spoke too soon. So my rule took and my Connections are being compressed but when I look at Traces the content-encoding is still set as deflate vs. GZIP.

 

 

Is my Rule logic off here?

 

 

-t

 

 

 

Here is my rule:

 

===================================

 

[root@xxxxxx:Active] config b rule force_gzip list

 

rule force_gzip {

 

when HTTP_RESPONSE { COMPRESS::method prefer gzip ;event disable }

 

}

 

[root@xxxxxx:Active] config

 

 

 

Here is my Virtual:

 

===================================

 

[root@xxxxx:Active] config b virtual list

 

virtual VIP1 {

 

destination x.x.x.x:http

 

ip protocol tcp

 

profile HTTP_compress oneconnect tcp

 

pool LOGIN12

 

rule force_gzip

 

}

 

[root@xxxxxx:Active] config

 

 

 

Here is my Trace:

 

===================================

 

GET / HTTP/1.1

 

Accept: */*

 

Accept-Language: en-us

 

Accept-Encoding: gzip, deflate

 

User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT 5.0)

 

Host: c.x.x.x

 

Connection: Keep-Alive

 

Cache-Control: no-cache

 

Cookie: MC1=V=2&GUID=xxxxxxx

 

 

 

 

HTTP/1.1 200 OK

 

X-Cnection: close

 

Date: Sat, 26 Mar 2005 00:50:35 GMT

 

Server: Microsoft-IIS/6.0

 

P3P:CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"

 

X-Powered-By: ASP.NET

 

X-AspNet-Version: 1.1.4322

 

Set-Cookie: CULTURE=en-US; domain=.xxxx.com; expires=Thu, 26-Mar-2015 00:50:35 GMT; path=/

 

Set-Cookie: mh=MSFT; domain=.xxxx.com; expires=Thu, 26-Mar-2015 00:50:35 GMT; path=/

 

Set-Cookie: SPEED=N; domain=.xxxx.com; expires=Fri, 08-Apr-2005 23:50:35 GMT; path=/

 

Cache-Control: no-cache

 

Pragma: no-cache

 

Expires: -1

 

Content-Type: text/html; charset=utf-8

 

Vary: Accept-Encoding

 

Content-Encoding: deflate

 

Still no love. My Traces still show Deflate in the CONTENT-ENCODING Header....

Mr -t, looks like you have found a problem with the Deflate filter. We will try to se what we can do to get this fixed asap, but in the mean time can you give this rule a whirl.

rule gzip { 
  when HTTP_RESPONSE { 
     COMPRESS::method prefer gzip 
     event disable 
  } 
  when HTTP_REQUEST { 
   if {[HTTP::header exist "Accept-Encoding"]} { 
     HTTP::header replace "Accept-Encoding" "gzip" 
     event disable 
   } 
  } 
 }

Ok, this workaround seems to work and my CONTENT-ENCODING Headers are now properly showing as GZIP. Getting this fixed soon would be great and since you guys usually GUI-ify any rule that gets alot of use, you should probably add this GZIP vs. DEFALTE Rule to the HTTP Profile in 9.0.

 

 

 

Some questions then:

 

===========================================================

 

1.) Is the perf hit on this workaround rule significantly more than the original one?

 

 

2.) Based on the way I am interpreting the workaround rule it appears that the top part is the same as the original rule we tried and the bottom part tells BIGIP to re-write the ACCEPT-ENCODING Header request from the Client so that BIGIP never sees the Deflate Option in the Client's request. If this is the case, why do we still need the original rule as part of this workaround rule?

 

 

3.) How would the workaround rule handle a situation where my browser supports Compression but only the Deflate method and not GZIP. If I am reading the rule correctly if BIGIP got an ACCEPT-ENCODING Header with just Deflate in it, BIGIP would parse it, see that the ACCEPT-ENCODING Header is present and then just re-write it to GZIP which the Client wouldn't support in this case. Granted I am not sure if there is a Browser version that support only Deflate but I thought I'd ask.

 

 

-t

1) Yes. Inserting a header is more expensive than changing some internal state in compression processing. UnRulely recently posted some information about enabling rule timing metrics which could help determine how much more expensive. However, the best way is always to benchmark it.

 

 

2) I agree. I don't think you need the original rule.

 

 

3) I agree again. You should scan the header value to make sure that gzip is supported by the client before you rewrite it.

 

 

I should also mention that I tracked down the problem with the COMPRESS::method prefer command. We'll have it fixed in a future release.

So based on all of the changes we talked about, I just want to double-check that I now have the right rule rule that removes the original rule + does the GZIP check in the ACCEPT-ENCODING Header.

 

 

I removed the original rule and I am assuming that the "exist" function will scan the entire header and thus instead of matching "Accept-Encoding" we can just match on "gzip". If there's no GZIP then no need to rewrite anything.

 

 

Would this rule incorporate everything we talked about so far?

 

=================================================================

 

rule gzip2 {

 

when HTTP_REQUEST {

 

if {[HTTP::header exist "gzip"]} {

 

HTTP::header replace "Accept-Encoding" "gzip"

 

event disable

 

}

 

}

 

}

You are very close. The header 'exist' command does not check the header value, it works only on the name. Lets scan the value for 'gzip' and convert it if one found.

rule gzip {  
    when HTTP_REQUEST {   
     if {[string first "gzip" [HTTP::header "Accept-Encoding"]] != -1} {  
       HTTP::header replace "Accept-Encoding" "gzip"   
     }   
    }   
   }

You may want to play around with adding back the 'event disable' command but I suspect that you might have to leave it out for keep-alive connections.