Forum Discussion
JN_42992
Nimbostratus
Nimbostratushttp 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
hoolioCirrostratus
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
JN_42992Thanks 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- hoolioIt'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
