Updates now max out IE's agent string length, causing problems

[GantryG]

Does anyone know what MS plans to do about the following problem caused by
updates?:

With the recent .NET 3.5 SP1 and Office Live Add-in updates, it is now the
case on some Windows installations that have all Windows patches for Windows
XP, at least, to max out the IE "user agent string" sent by IE to web sites
(260 characters), at which point JavaScript will fail to get the agent string
from IE (except the IE version, apparently) which breaks the ability of web
sites to sniff the .NET CLR info (or Windows version, or anything else
advertised in the string), which breaks some web sites.

Here is an example IE agent string from my Windows XP Tablet PC:
User-Agent - Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tablet PC
1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR
3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.1; .NET CLR 3.0.4506.2152;
.NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)

[PA Bear [MS MVP]]

[Crossposted to IE General newsgroup]

Please state your full Windows version (e.g., WinXP SP3) and full Office
version (e.g., Office 2007 SP1).

May we assume that the machine is fully patched at Windows Update?

Can you post examples of websites where you encounter the problem you
described?
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Desktop Experience - since 2002
AumHa VSOP & Admin http://aumha.net
DTS-L http://dts-l.net/

[Robert Aldwinckle]

"GantryG" <Gan...@discussions.microsoft.com> wrote in message news:727BE0BA-91C8-456F...@microsoft.com...

> Does anyone know what MS plans to do about the following problem caused by
> updates?:

http://www.fiddlertool.com/useragent.aspx

[GantryG]

Sure, it's XP Tablet SP3 with all of the patches from Windows Update, and
Office 2003 SP3 with Infopath (you can see that Infopath puts an entry in the
agent string.)

As for a web site, my Blue Coat RA (SSL VPN) fails to detect the OS because
it uses JavaScript to detect the OS in the agent string because of the max
out, so it denies access to the web site with "OS unsupported" because IE
just reports the IE version, not anything else when maxed out. This will be
a problem for any web site that sniffs for .NET CLR info or OS versions from
the agent string using JavaScript.
I don't want to give my SSL VPN web site address out for security reasons.
This just became a problem with the new updates that add to the agent string
quite a bit, and with my laptop having InfoPath and Tablet, it is over the
limit.
Blue Coat support says "use Firefox", but I would rather that MS fix IE or
shorten up the agent string entries for some of its modules, etc.
Thanks

[GantryG]

Thanks Robert. I hope that MS addresses this issue before it blows up.

[PA Bear [MS MVP]]

Thanks for your feedback. I've attempted to Escalate this bug for you. If
you can find one or more public websites where you encounter the behavior,
we can make a better case.

Meanwhile, since the full KB951847 package updates most of the earlier .NET
Framework versions, you might begin a new thread in, e.g.,
microsoft.public.dotnet.framework newsgroup and ask if you can safely
uninstall some or all of the earlier versions now, thereby shortening the UA
string.
--
~PA Bear

[GantryG]

Thanks, I found this forum comment about the same issue regarding the NBC web
site, ignored on Microsoft Connect:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=362923&wa=wsignin1.0

I am not worried about uninstalling stuff- I can do that, it's just that
some fully 'Windows Updated' computers as per MS are having issues, and when
this breaks to the press, they will be making fun of MS breaking stuff again
with Windows Update, and it is already causing me problems with my users.

[JW]

Pa Bear asked me to repost this here as it may be related:

Interesting problem with a long description, I have been at this a while
please be patient.

I have a fairly large network (over 1000 workstations). Internet Explorer 7
intermittantly has "Page Cannot be Displayed" error on several sites we use
everyday. If you refresh or click the link (or favorite) multiple times the
page will eventually load. I am using Active Directory, Filtering, Firewall,
Anti-virus etc, so I started eliminating. (I have read all of the previous
posts)

Here is where I am at now. Windows XP Pro. SP3 (freshly loaded) and Internet
Explorer 7. I have gone as far as to bypass everything in my network and
statically assign an address from the ISP and plug in directly to an outside
ISP port. I have no AD, no filter, no firewall, no anti-virus, no add-ons and
default IE security settings (cringe). Yes, I even ran IE with no addons.
If I apply all of the updates (as of 2-4-09) -except- the .NET updates (any
.NET including service packs) the workstation works as it is supposed to.
Once I install any of the .NET updates the behavior returns. I have ran a TCP
dump to examine the packet traffic. What i see is the browser contacts the
remote server, and starts sending traffic, this just stops and then all I see
is keep-alives every 10-20 seconds until it times out and displays the error
"Page Cannot be Displayed". If the refresh button or the link (favorite) is
clicked several times prior to the error, the page will eventually load. This
is not https and is not just one site. It is not a DNS or bandwidth issue. If
I try to uninstall the .NET updates, it still will not work. I have to take
it back via a restore point to make it function properly.
As another test, I fully patched the system (as of 2-4-09) including the
.NET updates and installed Firefox 3.0.6. The behavior does not repeat if FF3
is used as the browser. I would rather not deploy FF3 throughout the network.
I really do not want to try to restore every workstation either.
This is not critical but is extremely annoying, the end users are not happy.
I am looking for any debugging advice or thoughts on what to look at next.

[PA Bear [MS MVP]]

[Thanks!]

[Patrice]

Hello,

With a too long user agent this script :
parseFloat(navigator.appVersion.split('MSIE')[1])
return 6 instead of 7 on MSIE 7...
(and navigator.userAgent now only return "Mozilla/4.0 (compatible; MSIE 6.0)")

With this issue we falsly detect MSIE7 browsers as MSIE6 on skyrock.com
website and asking users to upgrade their browser to MSIE7 on MSIE6
incompatible parts of skyrock.com (advanced javascript).

I think it is one of the most proper way to get MSIE's version number in
javascript ?

My user-agent :
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET
CLR 1.1.4322; Media Center PC 4.0; .NET CLR 2.0.50727; InfoPath.1; .NET CLR
3.0.04506.30; .NET CLR 3.0.04506.648; OfficeLiveConnector.1.3;
OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
(no crap string from any toolbar, only MS .Net revisions .... )

This bug is perfectly described on
http://jamazon.co.uk/web/2008/07/23/an-ie7-bug-that-returns-msie-60-user-agent-string/ and i think may affect a lot of website.

[Patrice]

Hello,

With a too long user agent this script :
parseFloat(navigator.appVersion.split('MSIE')[1])
return 6 instead of 7 on MSIE 7...
(and navigator.userAgent now only return "Mozilla/4.0 (compatible; MSIE 6.0)")

With this issue we falsly detect MSIE7 browsers as MSIE6 on skyrock.com
website and asking users to upgrade their browser to MSIE7 on MSIE6
incompatible parts of skyrock.com (advanced javascript).

I think it is one of the most proper way to get MSIE's version number in
javascript ?

My user-agent :
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET
CLR 1.1.4322; Media Center PC 4.0; .NET CLR 2.0.50727; InfoPath.1; .NET CLR
3.0.04506.30; .NET CLR 3.0.04506.648; OfficeLiveConnector.1.3;
OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
(no crap string from any toolbar, only MS .Net revisions .... )

I think this bug could affect a lot of website using navigator javascript
object to detect browser version. I think it could affect also a lot of
company using .Net on internet exploer and detecting .net available version
by using navigator. (but i dont think user agent should be used to do that...
it's another story.)

[Patrice]

Hello,

With a too long user agent this script :
parseFloat(navigator.appVersion.split('MSIE')[1])
return 6 instead of 7 on MSIE 7...
(and navigator.userAgent now only return "Mozilla/4.0 (compatible; MSIE 6.0)")

With this issue we falsly detect MSIE7 browsers as MSIE6 on skyrock.com
website and asking users to upgrade their browser to MSIE7 on MSIE6
incompatible parts of skyrock.com (advanced javascript).

I think it is one of the most proper way to get MSIE's version number in
javascript ?

My user-agent :
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET
CLR 1.1.4322; Media Center PC 4.0; .NET CLR 2.0.50727; InfoPath.1; .NET CLR
3.0.04506.30; .NET CLR 3.0.04506.648; OfficeLiveConnector.1.3;
OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
(no crap string from any toolbar, only MS .Net revisions .... )

I think this bug could affect a lot of website using navigator javascript
object to detect browser version. I think it could affect also a lot of
company using .Net on internet exploer and detecting .net available version
by using navigator. (but i dont think user agent should be used to do that...
it's another story.)

"PA Bear [MS MVP]" wrote:

[GantryG]

This appears to be a different issue- it does not appear to involve a
maxed-out user-agent string, but seems to be related to .NET components
causing some kind of issue in your network. I think that I saw a similar
issue caused by a (hardware) firewall that had application filtering turned
on, causing odd timeout issues due to bugs in its code- if you have a
firewall, maybe try turning off the application/IDS/anti-virus/etc. for a bit
and see.