CODEWITHSUNDEEP
asp.netwebformsuser-agent
marc_s
marc_s

Reputation: 754598

User Agent switching in the middle of a request?

I have a really odd problem here - ASP.NET 3.5 Webforms app on IIS 6.

The effect is that the user connects to our site, and gets an ASP.NET session, enters some data and suddenly, all his data entered (and stored in the session) is gone.

Error logs shows us that for some odd reason, he's just getting a new session in the middle of working in our app.

From the IIS logs, we see that within a single ASP.NET request, the user agent reported from the user's browser switches - from MSIE+7.0 to MSIE+8.0.... how can that be?

Excerpt from log:

07:06:38   GET /SomePage.aspx  80 - x.x.x.139   Mozilla/4.0+ (compatible;+MSIE+7.0;+Windows+NT+5.1)   401 
07:06:38   GET /SomePage.aspx  80 DOMAIN\USERNAME  x.x.x.139  Mozilla/4.0+ (compatible;+MSIE+7.0;+Windows+NT+5.1)   200

07:06:39   GET /javascript/somefile.js 80   DOMAIN\USERNAME x.x.x.139   Mozilla/4.0+ (compatible;+MSIE+8.0;+Windows+NT+5.1)  200 
(lots more requests for .css, .js, .gif, .jpg - all with MSIE+8.0 ....)

It seems the two requests to the .aspx page are done in MSIE+7.0 mode, while any subsequent requests for CSS and JS files as well as GIF und JPG graphics report back MSIE+8.0 ...... WTF?!?!?

Not sure if that really is the root cause of the sudden loss of ASP.NET session - but that user agent switching in itself leaves us scratching our heads.... any ideas?

If this behavior is not the root cause of those "lost sessions" - any ideas / leads as to what could be the cause there? I haven't been able to dig up anything overly useful so far from here, Bing, Google or any other source....

Update: I read in this forum thread that the fact the user agent is different between the first GET (which fetches the .aspx page) and the subsequent GET requests for the .css, .js could cause the session to be lost (this is a PHP environment, though). Can anyone confirm whether this applies to ASP.NET, too? (or show that this statement is not true)

If this really is the case - is there any way to tell ASP.NET not to start a new sesssion just because the user agent string doesn't match the previous request?

Upvotes: 8

Views: 1095

Answers (1)

Spudley
Spudley

Reputation: 168715

What you've described here does indeed sound pretty odd.

Without seeing it in action it's hard to be certain what's going on, but (excluding UA spoofing) there's only one thing I can think of that could be at work here: compatibility mode.

I'm not aware of IE providing different UA strings for different request types, even in compatibility mode, but I guess it's possible.

But in any case, my suggestion would be to aim to prevent IE from using compatibility mode at all, by adding the X-UA-Compatible meta header to your page. Something like this should do it:

<meta http-equiv="x-ua-compatible" content="IE=edge">

Add it near the top of the <head> section of your HTML code.

This should force IE to use it's best rendering engine for the page. No more compatibility mode. So if this is the cause of your mysteriously changing UA string, it should solve that.

(Of course, if the user has a browser that spoofs the UA string, all bets are off. But even then it would seem odd for them to want to do that in the middle of a session)

Upvotes: 1

Related Questions