Forum Discussion

rb1980_75708's avatar
rb1980_75708
Icon for Nimbostratus rankNimbostratus
Nov 21, 2008

not caching on stream_matched problem

I have an interesting problem I'm hoping can be solved with an iRule:

 

I have a cgi that proxies to a back-end verity cluster to retreive search results. Occasionally, (because of a problem on the verity servers) I get a bogus reply with 0 results. This ends up getting cached on WA and served to subsequent requests for the same search.

 

Here is an example of one of the bogus search results:

 

 
 { 
   "gutter_url" : "", 
   "sort_order" : "popularity", 
   "sort_by" : "album", 
   "num_results" : 0, 
   "status" : "SUCCESS", 
   "type" : "BROWSE", 
   "elapsed" : 10.086959 
 } 
 

 

 

I'd like to have rule that follows this basic logic:

 

 

1. Identify search request by uri starts_with "/search-cgi"

 

2. Look for above string '"num_results" : 0,' in response to above request.

 

3. Tell WA to not cache this response.

 

 

I have the basic shell of the iRule as follows, but it's not working: The WAM is still caching the response and serving the next request with X-Pvinfo code S10102. Another thing I cannot figure out how to do is send a no-cache header on the response so the client browser does not cache it locally.

 

 

I'd appreciate any help with this.

 

 

 
 when HTTP_REQUEST { 
   set searchreq 0 
   if { [HTTP::uri] starts_with "/search-cgi" } { 
     set searchreq 1 
     log local0. "SEARCH REQUEST: [HTTP::uri]" 
   } 
 } 
  
 when HTTP_RESPONSE { 
   STREAM::disable   
   if {$searchreq == 1} { 
      STREAM::expression {@"num_results" : 0,@} 
      STREAM::enable 
   } 
 } 
  
 when STREAM_MATCHED { 
   set badreq 1 
   log local0. "BAD SEARCH RESULT: [STREAM::match]" 
    not working for WAM: 
   CACHE::disable  
 } 
  
 
  • I suspect (but can't find any proof at the moment) that the CACHE::disable only works for LTM RAM cache, not WAM, am I right? (still learning). If so: Is there any other method available via an iRule to tell WAM to not cache?
  • Hi RB,

     

     

    I'm not sure how you could disable WAM caching on a response. Assuming you can, I think you'd need to collect the payload using HTTP::collect in order to disable caching as the stream match event might be triggered after the response is already being transmitted to the client. Spark described this in a related post

     

     

     

    http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=18766&ptarget=18887

     

     

    Since the stream profile is designed to do minimal buffering of server response data, it's quite possible that the client would already have gotten part of the server response by the time the STREAM_MATCHED event fired.

     

     

     

     

    Maybe someone else can explain whether it's possible to/how you'd disable WAM caching in the response. You might take a look at the _sys_WA_ramcache_clientside rule in the /config/profile_base.conf file to see what the TMM-WAM rule is doing.

     

     

    Aaron
  • I'll start with the easy question first - how to send a no-cache header in the response so the client does not cache the item. This is controlled from within the policy's lifetime settings. The last section is the client cache settings there are options for do not change which will pass on the settings from the origin server, maximum age where you can specify a lifetime, and Insert no-cache directive which will instruct the client not to cache.

     

     

    WebAccelerator currently sets all of it's caching rules based on the request not on the response so preventing the caching of a response is not an easy feat in fact it may not be possible. I'll check around to see if this is possible but chances are it isn't.

     

     

    Finally the sys_WA_ramcache_clientside rule should not be edited unless explicitly told to do so from F5 support. Making changes to this will likely void your support contract.
  • looks like this is not something the WA can do... will need to try and solve the problem on the origin side.

     

    If anybody comes up with any ideas on how this might be done, please post here!
  • I wasn't suggesting editing the stock WA iRule--just looking at it to see if there are any hooks that would allow for disabling caching. In the pre-9.4.2 ASM clientside rule you could bypass ASM on requests by setting asm_bypass to 1 in a separate iRule on the VIP. Even so, editing the rule shouldn't invalidate your support contract. I think you'd just have to change it back to the original version in order to get support for the configuration.

     

     

    Aaron