Manipulating origin response

This has come up for me again... this time I need to "scrub" some unique data in the origin reponse, cache it, and put something else back in it's place on the way out.

I'm guessing based on previous questions I've asked on this forum that this is not possible.

Best I can tell, this is the sequence of events:

May  5 13:29:33 local/tmm1 info tmm1[5096]: Rule events : CLIENT_ACCEPTED
May  5 13:29:33 local/tmm1 info tmm1[5096]: Rule events : HTTP_REQUEST
May  5 13:29:33 local/tmm1 info tmm1[5096]: Rule events : HTTP_CLASS_SELECTED
May  5 13:29:33 local/tmm1 info tmm1[5096]: Rule events : SERVER_CONNECTED
May  5 13:29:33 local/tmm1 info tmm1[5096]: Rule events : HTTP_REQUEST_SEND
May  5 13:29:33 local/tmm1 info tmm1[5096]: Rule events : HTTP_RESPONSE

Where in here does stuff get sent to WAM?

Is there a way to mess with the "priority" to get at it before it goes to cache?

It depends on the version. In versions 9.4.x there is an internal iRule that needs to be edited support should be contacted if you need to do this. In versions 10.x the http_response event fires on the response from the origin and can be used to modify data prior to reaching WA.

 

 

Dawn

Thanks, Dawn. I'm working on 10.x.

 

Now, what about after the response has gone to WA and is served as a cache hit?

 

In that case, I don't see any HTTP_RESPONSE being triggered.

 

Is there some other event I can use to modify the response post-cache?

 

Let me explain more on what I am trying to do: maybe someone can help...

I have a legacy application that I want to put behind cache.

 

The problem is, the app was not written in such a way that is it cacheable: every request comes in with a sessionKey query parameter and the app generates pages that contain links with that sessionKey query parameter included.

 

I'm ignoring the sessionKey query parameter in the policy, so pages will get cached, but then then when user B comes along and gets the page from cache, it contains user A's sessionKey.

 

Originally I was thinking of an iRule that would strip out the sessionKey and replace it with a token, then put a new sessionKey in, but then I realized it would be easier to just change the origin to hand out a token in place of the sessionKey. So now I need an irule to replace the token with the sessionKey from the request query parameter on the response... AFTER cache.

 

I took the cookie/ssn scrubbing rule on DC and modified for my case, and it works to do the replacement, but since it happens on HTTP_RESPONSE (pre WAM as Dawn pointed out), the page is getting cached with the new sessionKey. Not exactly what I want.

 

It seems that on a cache hit, the CACHE_REQUEST and CACHE_RESPONSE events get triggered, but you can't seem do do any kind of manipulation like HTTP::collect in the CACHE_RESPONSE event.

 

Is there ANY way to accomplish this?

 

Thanks for providing more clarification on what you're looking to do. There are 2 potential ways to do this. Within the assembly tab in the policy there is an option called "Parameter Value Substitution" that may work. Otherwise you will need to use a VIP targeting VIP configuration in order to modify the response after it has been cached as there is currently no iRule event to trigger on the response from the WebAccelerator.

Oh wow, the "Parameter Value Subsititution" is exactly what I need to do. (I never looked at that feature before!!)

 

Unfortunately, it looks like it's designed to only work on HTML pages... the app I'm working with happens to be an api that returns xml or json data.

 

Bummer! Is there any way to tweak it to work with other content types? or is it specifically looking for "a href=" HTML tags?

 

 

I might have no choice but to do the VIP idea.

 

This did occur to me before, and I tried something similar that didn't work: I created a "B" vip on port 8080 with WAM enabled and pointed the http profile on vip A to a pool consisting of a node pointing to the 8080 port of vip B. The traffic never got to B.

 

Can you point me in the right direction on how to set that up? Does it need to be a different type of vip like forwarding (i did as standard)?

PS: I did try the Parameter Value Substitution on the policy and it didn't seem to work for these links.

this is what my xml links look like:

 http://api.mydomain.com:8080/getpage?format=xml&countryCode=US&sessionKey=foobarblah&maxResults=10&startPosition=10

haha. Deja Vu.... I just ran across one of your old posts that addresses the vip-targeting-vip:

 

 

http://devcentral.f5.com/weblogs/da...rules.aspx

 

I'll give that a try.

SUCCESS! I got it working with the vip-targeting-vip as you suggested. Thanks for the nudge in the right direction!

 

I still would be interested to see if there is a way to do this with the built-in functionality in the policy for different content types...

 

I look forward to hearing a response on that question.

I do have one more thing maybe you can help clarify:

 

I used the sample iRule CreditCardScrubberUsingStream from codeshare as the basis for my solution. The comments make reference to SOL6741, which says it was fixed way back in 9.4.

 

Do I need to worry about that 4MB limit on the stream filter, or can I strip that code out?

 

(I doubt any of the pages are bigger than 4MB, but the less code the better, right?)