Forum Discussion
Chris_Phillips
Nimbostratus
Nimbostratuscaching images - ignore HTTP request?
Howdy,
I'm updating some inherited rules to cache images:
when HTTP_REQUEST {
set filematch 0
Check if requested URI ends with the cache control file types or
the Content-Type equals any of the cache control content types
if { ([class search cache_control_files_dgl ends_with [HTTP::uri]]) or \
([class search cache_control_types_dgl equals [HTTP::header Content-Type]])} {
set filematch 1
}
}
when HTTP_RESPONSE {
if { $filematch == 1 } {
HTTP::header replace "Cache-Control" "max-age=3600,post-check=3600,pre-check=43200"
}
}Secondly, it seems to me that checking the HTTP::uri is pretty pointless when you have the Content-Type available in the response. I'm looking at replacing it with just this:
when HTTP_RESPONSE {
if { [class search cache_control_types_dgl equals [HTTP::header Content-Type]] } {
HTTP::header replace "Cache-Control" "max-age=3600,post-check=3600,pre-check=43200"
} else {
HTTP::header replace "Pragma" "no-cache"
HTTP::header replace "Expires" "-1"
HTTP::header replace "Cache-Control" "no-cache,no-store,must-revalidate"
}
}Whilst it can seem "safer" to check the URI, why would you ever need to IF you trust your application to be returning a correct Content-Type header? That is surely much more trustworthy that the requested URI?
Michael_YatesHi Chris,
I am guessing that you do not want to use the normal RAM Cache provided in the LTM and that you are not using the IBR (Intelligent Browser Referencing) from WA (Web Accelerator) and plan on modifying the "Cache-Control" value manually.
While this is an RFC Standard 14.9 Cache-Control, this will only work if the browser is RFC Compliant.
Have you thought about using a combination of RAM Cache to remove the load from the servers, and trying to modify the Cache-Control Value to remove the load from RAM Cache at the same time? (If the browser is not RFC Compliant the load would still be off-loaded from the servers by RAM Cache).
To answer your questions about URI checking, it is the default methodology for caching things in RAM Cache with just the LTM, I am not sure what qualifiers are used in WA, but it does seem safer to use the URI Value.
What you are doing does seem really interesting, I've never thought of doing it before. Can you post back some of your results?
Chris_PhillipsWell the positive caching side of things is officially deemed to be working satisfactorily, so it's not in my remit to poke too much on that side of things, RAM Cache is not being used, and won't be. And no sign of WA on this project, no, although I've had a bash at selling it to them!
The primary issue I'm trying to fix is that some sensitive data is being cached when it shouldn't be, so I'm officially just stopping the bad caching happening. And yes, certainly we're always at the mercy of RFC compliancy.
So you think that there is merit is using the suffix on the URI still despite being able to use the Content-Type header in the response? Can you explain more about the need to do this?
hooleylistCirrostratus
Hey Chris,
I wasn't involved in the testing for that iRule back when it was implemented on 9.x or for the most recent rewrite. But I think the logic for setting the cache-control headers in the response could have either been applied based on the requested URI or the response content-type header. I don't know of any specific difference or advantage between either approach.
Aaron- Chris_PhillipsThe content-type check does seem to be well after your involvement with it. Do you ever realistically come across well written web apps which won't provide a highly reliable content-type string?
- Chris_PhillipsThe content-type check does seem to be well after your involvement with it. Do you ever realistically come across well written web apps which won't provide a highly reliable content-type string?
- hooleylistNo. I don't think the client would process the content correctly if the content-type was set incorrectly.
Aaron