iRule action after ASM

I'm curious to see what are you trying to do. Can you describe what/why?

 

 

After upgrading to 9.2.4, you can select a pool in HTTP_CLASS_SELECTED which is triggered if the request matched an HTTP class on the VIP.

 

 

Check this post for details (Click here)

 

 

This event is triggered before TMM sends the request to ASM. There is no direct access from a rule for making changes to the serverside connection from ASM to TMM or from TMM to the node.

 

 

Aaron

Hi!

 

 

I've also have to do some iRule after ASM. Why? because I have to do a cookie change after ASM has inserted it's cookie.

 

 

The idea is to send A SINGLE COOKIE to the client (some old clients only support 1 cookie!) so I have to write an iRule that applies in 2 events:

 

 

- When the client send data, BEFORE asm get's the content, so I can re-write both cookies (server session and ASM)

 

- When the server sends data, AFTER asm puts his cookie, so I can "join" both cookies (server session and ASM) into a single cookie

 

 

Therefore, is there an event that applies AFTER asm? or is there a way for ASM NOT to put ANY cookie?

 

 

Thanks!

With the introduction of the plugin architecture in 9.4.2, the events for ASM enabled VIPs has improved significantly. In a standard HTTP VIP with at least one ASM-enabled HTTP Class added, the following events are potentially triggered:

 

 

CLIENT_ACCEPTED

 

HTTP_REQUEST

 

HTTP_CLASS_SELECTED

 

-- ASM request validation --

 

HTTP_CLASS_FAILED

 

LB_SELECTED

 

PERSIST_DOWN

 

LB_FAILED

 

SERVER_CONNECTED

 

HTTP_REQUEST_SEND

 

HTTP_RESPONSE

 

-- ASM response validation --

 

 

You can get definitions for when the various events are triggered from the events page ((Click here)).

 

 

You can modify the HTTP headers and data for a request before the request is sent to ASM for validation using the HTTP_REQUEST event. You can modify the request after ASM validation using LB_SELECTED (or HTTP_REQUEST_SEND and the clientside command (Click here).

 

 

Unfortunately, the only response event we have to work with is HTTP_RESPONSE. This is triggered when the server's response HTTP headers are parsed. The response is then sent to ASM. I don't think there is another event triggered after ASM has validated the response. So I don't think you will be able to modify the response after ASM processes it and before it is sent to the client.

 

 

It would be useful if there was an event triggered after ASM parsed the request and response. It would be great if we could get details on any violation which was found. I've requested this previously. At one point, F5 had spec'd the feature, but I don't think it's planned for any upcoming version.

 

 

 

Trigger an iRule event when an ASM violation is generated. Make the full request info accessible in a variable or array so the rule could have logic based on the violation type/data and modify the handling of the request/response. This would give administrators much more flexibility in how to handle violations.

 

 

 

 

If you want to request this functionality be added in a future version, you could open a case with F5 Support and ask them to attach your case to the request for enhancement.

 

 

Aaron

Hi pvalenzuela,

 

 

Also, ASM will insert a cookie to track data specific to a client's session. You can get some detail on this for 9.4.1 and lower in SOL6850 (Click here). I don't think there has been an update to this solution for 9.4.2 and later, so it's not complete for the latest versions.

 

 

Here are scenarios where ASM would track session data:

 

 

Dynamic parameter enforcement

 

Tracking domain cookies haven't been modified

 

Path sequence enforcement

 

 

What type of HTTP client only supports a single cookie? I've never heard of this before. Even if you could modify the response after it is parsed by ASM and before it's sent to the client it would be a bit difficult to handle the different cookie properties. How would you handle it if the app set a timeout or path for its cookie, but ASM didn't? What if the app specified the cookie should only be sent by the client over HTTPS?

 

 

Aaron

Well, try old nokia phones... unfortunetly, this is the case, and since the phone only supports 1 cookie, the server sends a session cookie and ASM inserts another one, i must create an iRule to make it "single-cookie" at the client side.

 

 

Maybe store it in some local variable? any ideas?