Forum Discussion

Steve_Luke_8796's avatar
Steve_Luke_8796
Icon for Nimbostratus rankNimbostratus
Mar 15, 2012

HTTP Compression and the Vary Header

So here is a problem we just came across.

 

 

We have an Virtual Server which has the oracle_as_http-wan-optimized-compression http profile assigned to it. The default compression values are set to a minimum of 1024 bytes. It also has the 'Vary' header insert ticked.

 

 

 

The problem is this. If any objects under 1024 bytes pass through, they are not compressed, but the Vary header is added anyway, which seems kind of pointless to me, as a proxy server would never receive this object compressed, and therefore why would it need to have a variance for accept-encoding on the hash and keep two copies possibly.

 

 

 

The bigger issue, is that due to the way IE6-8 works, if they receive a uncompressed object that has a Vary header included, it will not cache it. This is causing performance problems for our high latency users, and i need to fix it.

 

 

 

I could lower the compression minimum threshold, which could end up increasing the latency of certain low size objects. I could remove the Vary header altogether would could provide an issue with any proxied connections. Or, could I disable the HTTP profile Vary header insert and write an iRule which checks the object size and then either adds it or doesnt?

 

 

 

I am raising a Support Case on the issue itself as i dont believe the LTM should be adding this header when the content is clearly not going to be compressed, but any help with the iRule or alternative options would be appreciated.

 

application delivery
dev
devops
iRules
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 17, 2012
    Hi Steve,

    Does the response have a content-length header set to a value less than 1024? If so, you could try something like this: 

    
when HTTP_RESPONSE {
if {[HTTP::header Content-Length] > 0 and [HTTP::header Content-Length] < 1024}{
HTTP::header remove Vary
}
}

    Aaron
  • Steve_Luke_8796's avatar
    Steve_Luke_8796
    Icon for Nimbostratus rankNimbostratus
    Mar 29, 2012
    Thanks hoolio, but isnt it the case that you cant remove something via an iRule that a HTTP profile inserts?

     

     

    I was thinking about doing it the other way around, so disabling the profile Vary insert, and using the iRule to insert a vary header only if the content length is above a certain limit that i know we will compress at. I guess i could just manipulate your sample to achieve the same thing.

     

     

    The question still stands though to the developers as to why we would do something that seems redundant. i.e. inserting a vary header when the profile is never going to compress it.
  • adharkrader's avatar
    adharkrader
    Icon for Nimbostratus rankNimbostratus
    Apr 13, 2012
    We're having a similar issue. By default, things like images aren't compressed but the Vary header is added anyway... so IE doesn't cache them locally.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Apr 13, 2012
    Thanks hoolio, but isnt it the case that you cant remove something via an iRule that a HTTP profile inserts?

     

     

    You should be able to modify the headers inserted by an HTTP profile. The profile actions happen just before HTTP_REQUEST and HTTP_RESPONSE are triggered.

     

     

    Aaron
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Apr 13, 2012
    What hoolio says is true, but in this case it isn't HTTP code inserting the Vary header, it's the compression code. So I don't think you'll be able to remove it in HTTP_RESPONSE. You could remove it in HTTP_RESPONSE_RELEASE if your version supports that event, but if your compression settings are still in your http profiles, then you're likely still on a 10.x or earlier release, which doesn't. What version are you on?

     

     

    You might be able to solve the problem by calling COMPRESS::disable explicitly in HTTP_RESPONSE if the response will never be compressed.

     

     

    Worst case, you could use a VIP-targeting-VIP, configure compression on the "internal" (non-customer-facing) VIP, and remove the header on the "external" (customer-facing) VIP.

     

     

    I'll check with some other people to see if they have some idea about configuring the compression settings to solve or mitigate this issue.