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

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)

[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/

GantryG wrote:
> 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)

"GantryG" <> wrote in message news:727BE0BA-91C8-456F-A164-...
> Does anyone know what MS plans to do about the following problem caused by
> updates?:


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


>
> 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)
>

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

"PA Bear [MS MVP]" wrote:

> [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/
>
> GantryG wrote:
> > 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)
>
>

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

"Robert Aldwinckle" wrote:

>
> "GantryG" <> wrote in message news:727BE0BA-91C8-456F-A164-...
> > Does anyone know what MS plans to do about the following problem caused by
> > updates?:
>
>
> http://www.fiddlertool.com/useragent.aspx
>
>
> >
> > 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)
> >
>
>
>

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 wrote:
> 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
>
> "PA Bear [MS MVP]" wrote:
>> [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/
>>
>> GantryG wrote:
>>> 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)

Thanks, I found this forum comment about the same issue regarding the NBC web
site, ignored on Microsoft Connect:
https://connect.microsoft.com/Visual...&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.

"PA Bear [MS MVP]" wrote:

> 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 wrote:
> > 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
> >
> > "PA Bear [MS MVP]" wrote:
> >> [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/
> >>
> >> GantryG wrote:
> >>> 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 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.

[Thanks!]

JW wrote:
> 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.

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/...-agent-string/ and i think may affect a lot of website.


"PA Bear [MS MVP]" wrote:

> 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 wrote:
> > 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
> >
> > "PA Bear [MS MVP]" wrote:
> >> [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/
> >>
> >> GantryG wrote:
> >>> 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)
>
>