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

Discussion in 'Windows Update' started by GantryG, Feb 3, 2009.

  1. GantryG

    GantryG Guest

    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, Feb 3, 2009
    #1
    1. Advertisements

  2. [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?
     
    PA Bear [MS MVP], Feb 4, 2009
    #2
    1. Advertisements

  3.  
    Robert Aldwinckle, Feb 4, 2009
    #3
  4. GantryG

    GantryG Guest

    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, Feb 4, 2009
    #4
  5. GantryG

    GantryG Guest

    Thanks Robert. I hope that MS addresses this issue before it blows up.
     
    GantryG, Feb 4, 2009
    #5
  6. 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
     
    PA Bear [MS MVP], Feb 4, 2009
    #6
  7. GantryG

    GantryG Guest

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

     
    GantryG, Feb 5, 2009
    #7
  8. GantryG

    JW Guest

    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.
     
    JW, Feb 7, 2009
    #8
  9. [Thanks!]
     
    PA Bear [MS MVP], Feb 7, 2009
    #9
  10. GantryG

    Patrice Guest

    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, Feb 8, 2009
    #10
  11. GantryG

    Patrice Guest

    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, Feb 8, 2009
    #11
  12. GantryG

    Patrice Guest

    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, Feb 8, 2009
    #12
  13. GantryG

    GantryG Guest

    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.
     
    GantryG, Feb 10, 2009
    #13
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.