HTTP Request Corruption

问题:

On a site that receives a very high amount of traffic some small percent of requests come like this:

http://cheezburger.com/ScriptResource.axd?d=zaVpgH63ePt90pn</a>                                                   <br />                        <br />                        <p>                            <a id=

On the page referrer page there is a line like so:

<script src="/ScriptResource.axd?d=zaVpgH63ePt90p8fuEYkPAKFZuziMYsiIUbmxDb-gQ23Cx78LNJNFXTqKciA4ND_frR-_r9UKsdtLPk6M08xyk6cXFSLUrbBGDlvPIf-F9w1&amp;t=ffffffffd5e08dd5" type="text/javascript"></script>

and another couple lines much further on:

    <a id="login_LoginState_LoginButton" class="button1" UseSubmitBehavior="false" href="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions(&quot;login$LoginState$LoginButton&quot;, &quot;&quot;, true, &quot;ctl00$Login1&quot;, &quot;&quot;, false, true))">Log In</a>
<br /> 
<br /> 
<p> 
    <a id="login_LoginState_PasswordRecoveryLink" href="/forgot.aspx">Forgot Password?</a> 

So it appears that part of the page has been removed. It appears to happen more often in IE than Firefox, but that might be because we have more IE traffic than FireFox. We have HTTP compression turned on, but I don't know if that is the problem.

So my question is what is going on and how can it be fixed?

回答1:

After looking at the automatic bug reports generated by this error, it seems the majority of the cases where this occurs is with clients going through proxies. I think this comes down to either a bug in the proxy or a bug in the gzip implementation on the proxy.

回答2:

If you've got a bit of time to diagnose and time to spare this, I have a potential suggestion for more information gathering:

Write a javascript check on the length of the page after loading, and make sure that value is the same as what the server thinks. If it isn't, check out whats going on. You could run this live, or run a browser farm against your server looking for the bug. This relies on the javascript check getting across intact, though.

This almost sounds like a bizarre network or server problem, which is why I'd suggest trying to get ahold of the client side's version of the page to see what they've got.

回答3:

Possibly this is due to the transmission of the page being chunked:

Paragraphs 3.5, 3.6 and 3.6.1 talk about how HTTP pages that use transfer-encoding like gzip must be chunked, unless they close the connection after the entire page has been sent.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5

I believe each chunk is independantly compressed, and one of those chunks might have gotten corrupt.

回答4:

This looks like one of the IE bugs. IE6 always had problems with gzipped responses and IE8 introduced new issues with the Lookahead Downloader.

I think you might be dealing with the 'Missing 4k Bug' and the recommended workaround is to use a Content-Type HTTP header rather than a <meta http-equiv="Content-Type"/> tag for charset declaration.

More Links:

• Microsoft Connect Entry with Response from Microsoft
• Related Stackoverflow Question
• Related Microsoft Connect Entry
• My Problem that turned out to be caused by this

回答5:

Difficult to say by just looking at it. It could be a framework that adds a session id for you as a fallback from cookie sessions. The small percentage could be users with disabled cookies?

A similar thing happens in Tomcat with JSession id.

回答6:

The "&" is correct. It's in a <Script> tag so it's ok to be like that. Check the source of a Asp.Net AJAX-enabled page and you'll see it'll be in that form.

Do you have the requisite <httpHandlers> section in your 'Web.Config' with the <add verb="GET,HEAD" path="ScriptResource.axd" ... /> entry? I'm just wondering if your app knows how to handle .axd files?

@leonm - the "d" parameter is the encoded resource key, added by Asp.Net AJAX. The "t" is the timestamp, used to determine when the assembly was last modified.