Forum Discussion

JN_42992's avatar
JN_42992
Icon for Nimbostratus rankNimbostratus
May 27, 2010

http response not always fired

Hi, I have the iRule below deployed on a chassis running 9.3.1 (latest HF). This iRule does not always work. In fact, after some debugging, I noticed that HTTP_RESPONSE is not always fired. Any idea why? Is this rule not written correctly? rule rule-client-cache-static-objects { when HTTP_REQUEST { if { [matchclass [string tolower [HTTP::path]] starts_with $::staticcacheable] } { set cacheHeader 1 } else { set cacheHeader 0 } log local0. "[HTTP::host][HTTP::path] cacheHeader is $cacheHeader" } when HTTP_RESPONSE { log local0. "HTTP_RESPONSE fired, cacheHeader is $cacheHeader" if {$cacheHeader} { HTTP::header replace Cache-Control "public,max-age=3600" } HTTP::header remove Etag } } staticcacheable is a list of URI like /js/, /css/, ... It has about 10 items. Thanks

3 Replies

  • Hi Jean,

     

     

    Are you using RAM cache on the HTTP profile for the virtual server? The HTTP_RESPONSE event is triggered when the pool member sends a response, LTM has an HTTP profile on the virtual server and LTM parses the response's HTTP headers. If a response is sent via RAM cache, HTTP_RESPONSE won't be triggered. Instead, CACHE_RESPONSE will be triggered when a response is sent.

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/cache

     

     

    You can use the CACHE::header command to retrieve or modify the headers that will be sent in a cached response:

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/cache__header

     

     

    If you're not using RAM caching on the VS, then is it possible that the server isn't sending a response when you don't see HTTP_RESPONSE triggered? Or do you have any other iRules added to the virtual server?

     

     

    Aaron
  • Thanks Aaron for the reply. I will keep the ramcache tips in mind for a different unit I have.

     

     

    For this particular unit, there is no ramcache enabled.

     

     

    The server is always sending a response to the browser (HTTP 200). There is no other proxy or caching appliance deployed. There is no other iRule.

     

     

    From the client perspective, HTTP_RESPONSE would be fired for 4 or 5 files in a folder for example. Let's say /css/ contains cacheable content. The Irule should be fired and the HTTP headers should be set accordingly.

     

    The client would see:

     

    - /css/file1.css with the correct HTTP headers

     

    - /css/file2.css with the correct HTTP headers

     

    - /css/file3.css with the correct HTTP headers

     

    - /css/file4.css without the correct HTTP headers. It has the original from the server.

     

    - /css/file5.css with the correct HTTP headers

     

  • It's a bit strange that HTTP_RESPONSE would not fire on all responses. Is this something you can reproduce? If so, can you capture a tcpdump of the client and serverside traffic and compare the responses that do trigger HTTP_RESPONSE with the ones that don't? You can use syntax like this:

     

     

    tcpdump -i 0.0 -s 0 -w /var/tmp/trace.1.dmp host CLIENT_IP or host POOL_IP_1 or host POOL_IP_2

     

     

    If you want help capturing or analyzing the tcpdump, you can open a case with F5 Support.

     

     

    Aaron