The problem is that the compression profile won't compress the response unless an Accept-Encoding header is seen in the HTTP request, and you are removing the Accept-Encoding header prior to the profile handling the traffic.
Here's a excerpt explaining the feature for v11.2, but it's not dramatically different in practice in v10:
When HTTP compression is enabled on the BIG-IP system, Local Traffic Manager performs a series of steps:
-
First, Local Traffic Manager reads the Accept-Encoding header of a client request, looks for specification of either the deflate or gzip compression method, and notes whether either method is marked as being preferred.
-
If the Keep Accept Encoding setting in the profile is set to Disabled, Local Traffic Manager then removes the Accept-Encoding header from the request and passes the request on to the server. Removing the Accept-Encoding header prevents the server from performing the HTTP compression and from inserting the Content-Encoding header into its response.
-
Upon receiving the server response, Local Traffic Manager inserts the Content-Encoding header, specifying the compression method that it has chosen to use. Local Traffic Manager chooses a compression method by looking for the specification of either the gzip or deflate compression method in the Accept-Encoding header of the client request. If the client request does not specify a compression method, Local Traffic Manager can use either the gzip or deflate method to compress the response data. In this case, the default method that Local Traffic Manager uses is gzip.
-
Finally, Local Traffic Manager then compresses the response and sends it to the client. The client then reads the Content-Encoding header in the response, determines the compression method used, and uncompresses the data accordingly.
It seems like the "Keep Accept Encoding" feature will manage what you are trying to do via the iRule and the compression profile.
Nimbostratus
