.net session id

A few stabs in the dark...

 

 

Is the client using pipelining to make multiple requests before it gets a response to the preceding requests? Can you disable HTTP 1.1 on the browser and still reproduce the issue? If disabling HTTP 1.1 on the browser resolves the issue, you could try using a rule to set the version to HTTP 1.0 for all requests that don't already have a UIE persistence record.

 

 

Edit: on second thought, why not just use cookie insert persistence rather than trying to persist off of the app's session ID in the ASPSESSIONID cookie?

 

 

Aaron

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

 

They have non standard browser and WAP device support, so oookies were not a long term option.

Ok, I have a very similiar issue here. I do a cookie insert via the ltm but still recieve errors like everyone else on the planet. The asp session id sounded like it would have worked if it was only 7 characters. Well that's not going to work here. I do need to insert a cookie and the path has to equal a forward slash "/" to get around the asp 2.0 issue. I will open another topic if no one is monitoring this still. I really don't have a clue on this kind of intense scripting. any help would be appreciated.

xf6svrb, you might do well to start a new post detailing the exact issue(s) you're encountering and what you'd like to try to do using an iRule to fix them.

 

 

Brad and/or Deb, I might be missing something, but I interpret that rule as saying:

 

 

Check the response from the server. If the response contains an ASP session ID cookie, grab the value and create a persistence record. On requests, look for the ASP session ID cookie, and persist off of it if there is matching persistence record for it.

 

 

I don't see how this is a workaround for clients who might not support cookies as it depends on the client presenting a cookie in order to find the persistence record.

 

 

It might be resource intensive, but could you use write a session ID in the URI similar to jsessionid persistence for clients that don't send cookies? Granted, you'd have to rewrite HTTP content as well as Location headers.

 

 

Aaron

that's what the rule above does, hoolio, and I agree that xf6svrb should start a new post with details of the specific problem he is trying to solve.

 

 

As for supporting cookies for cookie-less clients: Bottom line, if your clients don't handle cookies, figure out a way to have the real server insert URI-based session tokens instead.

 

 

I've written an iRule to proxy cookie values via the session table for non-cookie enabled clients, but I don't recommend that approach, in fact have recommended against it several times since, as it was a painful and time-consuming experience. The solution requires a number of complex regex substitutions, so it is very slow and a huge resource hog, and the full development of the algorithm to match the requirements of a specific site takes a good deal of trial and error to define every instance in which the data must be swapped, inbound and out. Even when fully optimized, the solution is limited as to the size of response pages that it can manage.

 

 

/deb