Forum Discussion
NimbostratusConditional caching using an iRule
Hi,
I am trying to conditionally disable ramcache from within an iRule, based on an HTTP class, but it is not behaving as I would expect. I am hoping someone here might be able to explain why.
Version is 11.2.1 HF6.
Background: we are trying to use ASM and ramcache on the same virtual server, and are more or less following SOL13112 to cache static content and send the rest to ASM. This procedure seems to have worked for us previously. This time... not so much.
The following iRule somehow causes nothing to be cached, even though the static class is being matched and the
CACHE::disablewhen HTTP_CLASS_SELECTED {
log local0. "Selected class [HTTP::class] for [HTTP::uri]"
if { not ([HTTP::class] eq "/custname/custname_test_web_http_static") } {
log local0. "Disabling cache for [HTTP::uri] ([HTTP::class])"
CACHE::disable
}
}
The HTTP class uses a regex match identical to the one in that SOL.
If I comment out the
CACHE::disableCACHE::disableCan anyone help me understand what I (or the LTM) is doing wrong here?
Many thanks in advance,
Phil.
6 Replies
- JRahm
Admin
Not familiar with that solution, but curious why if the only condition is negative and then disabling why the default behavior wouldn't be disabled and then you enable the cache for your specific condition. If you rework the iRule to enable the cache when the static content is detected, do you see a difference?
when HTTP_CLASS_SELECTED { CACHE::disable if { [HTTP::class] eq "/custname/custname_test_web_http_static" } { CACHE::enable } } 
pdhAdditional info: If I disassociate the other HTTP class (used to catch all other content for ASM) then **all** content gets cached. I think that makes sense -- no matching class means no HTTP_CLASS_SELECTED event to call on a CACHE::disable, so the cache remains enabled for all objects.- pdh
Actually.... upon closer investigation, even when there is no CACHE::disable, the static items are not being cached -- only things that shouldn't be. So the problem isn't in fact the conditional CACHE::enable/disable at all, it's that these items are somehow failing to be added to the cache for some other reason.
- JRahm
if the published solution isn't working for you, i'd recommend opening a case. I personally haven't cached and applied ASM on the same vip, I use a vip targeting vip solution, applying iRules, cache, and other attributes on the frontside vip and applying the ASM policy on the backside vip.
- pdh
And the answer was: Caching was working just fine, but the client I was using, even when asked to force-reload images was apparently still sending If-Modified-Since. So the correct logic was being triggered, and the logs verified that, but no content was actually being retrieved from the servers to populate the cache.
Combined with a logical error in the original iRule that I had already fixed (which set me off on this path in the first place), I have been chasing a ghost.
Complete PEBCAK. I am going away now to try to find a copy of "HTTP for Dummies".
- JRahmglad you found the issue. and thanks for the new acronym! Hadn't heard that one, I always use ID-10-t. :) There's so much on the stinkin' stack to learn between layers 1 and 7, anyone bored in this industry is wasting potential.
