IE 8 HTML parsing issues

Our site receives large amounts of traffic and since the initial release of
IE8 (~April 2nd 2009), we've seen errors that could be related to HTML
parsing errors coming in high volumes from IE 8 clients only. Details are
obfuscated for privacy reasons but are available upon direct contact.

Some of our pages load CSS content such as:
http://some.domain.com/css/merge.css....css/74606.css

our servers are receiving requests exclusively from IE8 clients for what
appears to be the CSS request above, but with a completely modified URI

instead of
[...]@style_indexie_2.css/74197.css
we receive requests for
[...]@style_indexieli>[followed by an extended amount of HTML/javascript
that is served on the initial page]

It seems that IE8 is basically having problems parsing the HTML of the
initial page. It truncates the original CSS resource's URL and appends
illegitimate HTML/JS from the actual page to it, causing invalid (and
problematic) requests.

We have found the following user agents in mass numbers within our logs:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6; SLCC1;
..NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618)

Urgent attention and response to this matter will be hugely appreciated.

Thomas wrote:
> Our site receives large amounts of traffic and since the initial release of
> IE8 (~April 2nd 2009), we've seen errors that could be related to HTML
> parsing errors coming in high volumes from IE 8 clients only. Details are
> obfuscated for privacy reasons but are available upon direct contact.

Does your page use JavaScript's document.write to create code on the
fly? Depending on the circumstances, this can confuse some parsers.

Validate your HTML code at this site:
http://validator.w3.org/

Validate your CSS code at this site:
http://jigsaw.w3.org/css-validator/

Fix the errors and see if the problems go away. Valid code will display well in
any browser, but, there will be some noticeable differences. Even valid code
can display very differently with differing DOCTYPEs.

The HTML and CSS standards describe what a browser should do with valid code, it
can not possibly describe behavior for all possible code errors. A parsing
error is not a browser bug unless it occurs with fully valid code. IE8 is far
less forgiving of page errors than earlier versions.

--
G. R. Woodring

Date: 10/21/2009 4:17 PM, Author: Thomas Wrote:
> Our site receives large amounts of traffic and since the initial release of
> IE8 (~April 2nd 2009), we've seen errors that could be related to HTML
> parsing errors coming in high volumes from IE 8 clients only. Details are
> obfuscated for privacy reasons but are available upon direct contact.
>
> Some of our pages load CSS content such as:
> http://some.domain.com/css/merge.css....css/74606.css
>
> our servers are receiving requests exclusively from IE8 clients for what
> appears to be the CSS request above, but with a completely modified URI
>
> instead of
> [...]@style_indexie_2.css/74197.css
> we receive requests for
> [...]@style_indexieli>[followed by an extended amount of HTML/javascript
> that is served on the initial page]
>
> It seems that IE8 is basically having problems parsing the HTML of the
> initial page. It truncates the original CSS resource's URL and appends
> illegitimate HTML/JS from the actual page to it, causing invalid (and
> problematic) requests.
>
> We have found the following user agents in mass numbers within our logs:
> Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR
> 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
>
> Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6; SLCC1;
> .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
>
> Urgent attention and response to this matter will be hugely appreciated.

Hi Thomas,

Is there a Squid in this? (viz. Are you using a Squid(or other) proxy?). If
you are I don't have an answer for your yet.... I am currently looking at a
similar problem.

Have you inspected your server code for any browser sniffing logic that
incorrectly detects IE8? All the UA strings you quoted look fine. You can
test your UA's at http://www.enhanceie.com/ua.aspx

To troubleshoot your response headers see
http://www.enhanceie.com/ie/troubleshoot.asp

Regards.

"Thomas" <Thomas@discussions.microsoft.com> wrote in message
news:6C356B2F-DC8D-4E45-945B-86CE1E5160D3@microsoft.com...
> Our site receives large amounts of traffic and since the initial release
> of
> IE8 (~April 2nd 2009), we've seen errors that could be related to HTML
> parsing errors coming in high volumes from IE 8 clients only. Details are
> obfuscated for privacy reasons but are available upon direct contact.
>
> Some of our pages load CSS content such as:
> http://some.domain.com/css/merge.css....css/74606.css
>
> our servers are receiving requests exclusively from IE8 clients for what
> appears to be the CSS request above, but with a completely modified URI
>
> instead of
> [...]@style_indexie_2.css/74197.css
> we receive requests for
> [...]@style_indexieli>[followed by an extended amount of HTML/javascript
> that is served on the initial page]
>
> It seems that IE8 is basically having problems parsing the HTML of the
> initial page. It truncates the original CSS resource's URL and appends
> illegitimate HTML/JS from the actual page to it, causing invalid (and
> problematic) requests.
>
> We have found the following user agents in mass numbers within our logs:
> Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR
> 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR
> 3.0.04506.648)
>
> Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6;
> SLCC1;
> .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
>
> Urgent attention and response to this matter will be hugely appreciated.

[acenet]

Quote:

Originally Posted by rob^_^

Hi Thomas,

Is there a Squid in this? (viz. Are you using a Squid(or other) proxy?). If
you are I don't have an answer for your yet.... I am currently looking at a
similar problem.

Have you inspected your server code for any browser sniffing logic that
incorrectly detects IE8? All the UA strings you quoted look fine. You can
test your UA's at Internet Explorer - User-Agent test and override registry scripts

To troubleshoot your response headers see
EnhanceIE.com - Troubleshooting Internet Explorer problems

Regards.

Hi,

are there any news about this? We're having the same issues here with IE 8 clients. We're using Squid..

Best Regards,

[smileham]

I'm seeing the exact same problem, only happens on IE8!

We've got quite a javascript heavy site, so I can see how this could be caused by an errant document.write, but it seems to happen quite consistently.

If anyone has any ideas, I'd really like to hear them!

"smileham" <smileham.47lyg2@no-mx.forums.vistaheads.com> wrote in message
news:smileham.47lyg2@no-mx.forums.vistaheads.com...

Wed, 21 Oct 2009 13:17:01 -0700
http://groups.google.com/group/micro...=author:acenet

poster is replying to another Me too!


>
> I'm seeing the exact same problem, only happens on IE8!
>
> We've got quite a javascript heavy site, so I can see how this could be
> caused by an errant document.write, but it seems to happen quite
> consistently.
>
> If anyone has any ideas, I'd really like to hear them!
>
>
> --
> smileham
> Posted via http://www.vistaheads.com
>