.net session id

Turns out that the sessionID's being set by the server in this case are actually longer than 7 characters, so the persistence entry never matches the cookie value.

 

 

We've adjusted the iRule to use the [HTTP::cookie] command to look for that specific cookie in the response, rather than using the [HTTP::header] command to grab the value from a Set-Cookie header, for 2 reasons:

 

 

1) [HTTP::cookie ] extracts the whole cookie value automatically, so you don't have to calc the offset and endpoint (very common cause of unintentional persistence values);

 

 

and

 

 

2) [HTTP::header Set-Cookie] will only see the last Set-Cookie header sent by the server, which may not be the one the iRule needs to look at. If the iRule never sees the correct cookie, the persistence value would be blank and no persistence entry would be written. (After looking at a trace of the traffic, I think that's likely what was happening.)

 

 

Hopefully Brad will let us know if that change resolved the issue...

 

 

And don't forget that logging any derived or assumed values (on both request and response for comparison if necessary as in this case) should help figure out what's going sideways.

 

 

/deb