Menu
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?
621
In user-agent spoofing, bad actors modify elements of the user agent string to obfuscate details of their traffic. For example, making high traffic volumes from a single device look like lots of individual advertising engagements from multiple devices.
AppleWebKit/537.36 indicates what browser rendering engine is used. A rendering engine is what transforms HTML into an interactive webpage on the user's screen. The WebKit browser engine was developed by Apple and is primarily used by Safari, Chromium, and all other WebKit-based browsers. (KHTML, like Gecko).
User agent parsing is a business-critical process, and WURFL provides more than 99% accuracy. Whether you are optimizing websites, analyzing visitors, or working on programmatic advertising, you need an accurate device detection API you can trust.
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)
164
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
