I added the following around my script and I have not scene the issue since. its odd because the google analytics code does not have this around it. the script that does is at the bottom of the page and is the last script in the page and uses JQuery. I dont
know why or how this fixed it beacuse I am also not using a XHTML doctype tag. but like I said have not scene it since so.... go figure
You should not worry about the parameters of the axd files. The parameters are generated based on the javascript/ajax you are using,
Normally we wouldn't, but it's generating them incorrectly, and messing things up.
Or at least, so it appears. I'm becoming convinced that .NET is doing its job just fine, and generating the page just fine...and the page is losing text somewhere after that point. For instance, if I look at one of my mangled URLs, all of the text is valid...even
the mangled part. It's just that the mangled part is supposed to be much later in my page. If I look at how much text is missing, it's exactly 4k. That, to me, smells fishy. Once I started looking around, I've noticed some other errors that could also
be this problem, but are showing up in different areas on the page (not in the middle of webresource.axd) so we were assuming they were different problems.
That might explain why adding CDATA tags "helped" joevolcano out...he could still be getting this issue of dropping 4k of text...but it's no longer starting in the middle of the webresource.axd url, so he doesn't see the same error message. If I'm right,
most of the time, in fact, no error will be thrown by this problem, since losing a chunk of text on the client side might cause the text to be missing a big chunk, look funny, etc., but the server would have no way of knowing this had happened.
We've had this issue cropping up with increasing frequency, without having had an overall spike in traffic. This increase seems to coincide with the beta and final releases of IE 8. I combine this with the fact that I've only seen this bug when the client
identifies itself as IE 8 or 7 (IE 8 will identify itself as IE 7 if it's in compatibility mode), and this makes me believe that there is a decent chance that IE 8 has some kind of parsing issue that is causing it to drop a memory page somewhere (hence the
4k chunk.)
You´re absolutely right. IE8 somehow tampers the d-Parameter, so that the query for the AXD-resource won´t return any javascript i think. Fortunately the user won´t notice this in all cases. I could reproduce the error by clicking around on our web page
very fast, and had those errors with my IP Address in my log files. While clicking around as a user i didn´t notice any problems.
very interesting. when I was getting the corrupted webresource.axd urls I did not examine the number of bytes between the url and the goofy txt. but they were all over the place so not sure they were exactly 4K though could still be because sometimes the
corrupted url was shortened at different lengths. I still have the google analytics javascript in the page. and I am not using the CDATA tags around it. I have not seen any errors since except a "unable to parse viewstate" but very infrequent nothing like
the webresource.axd which was occuring every hour. but this site also gets a lot of traffic. I would guess that if there was data being dropped or threads getting crossed when parsing by the client browser, it would cause this issue with the viewstate as well.
I am going to put the CDATA tags around the google analytics javascript next. I think you are probably correct that it is an IE8/IE7 compat mode issue. though I cant tell how to see if the browser is in compat mode from the request object.
4K sounds like a buffer size IMHO, infact I think the latest xml parsing objects from MS use a buffer read of CDATA in xml
though my doc type is
<!
DOCTYPE
HTML
PUBLIC
"-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Personally I am not "worried" about the parameters themselves what I am worried about is getting exceptions in my error log and users inconsistantly getting bad links because there browser cant resolve the javascript because the bad webresource paramaters
that you suggest not to "worry" about are present. did you even read the posts here? is this the consistancy of your over 5000 points? contribute something. or at least defend your ambigous opinion so that I can agree with you.
MattBrooks: How do you know it never shows up as an error to the user? My guess is that it does, but it's usually in somewhat subtle ways. For instance, if the link to WebResource.axd is bad, it won't load in that supporting JavaScript. No error will
necessarily be immediately obvious to the user from that problem...but some associated functionality, such as script validation may now fail.
It looks like most people are having problems with 4K being dropped from the html stream somewhere. Can you verify if that's what you're seeing as well?
We are actually seeing this problem in more places than we originally anticipated, but we weren't aware of them because the only time it was reported back to the server was when a url was bad (such as WebResource.axd), and then a request came back for that
URL.
I have been able to reproduce the issue in our staging and live servers. The behaviour I have observed is the browser always seems to load the .axd resources successfully when it doesn't have them cached, i.e. the first time they are loaded. It is only on
subsequent page loads that the mangled requests are generated. I'm not sure why the browser is generating the mangled requests though. It seems to have all scripts loaded successfully from its cache as no functionality is broken. Hence the user never experiences
any problem (in fact the user is not even aware of the additional mangled request).
I can confirm that I'm seeing data lost out of the stream. I am unable to confirm that it is exactly 4k but I suspect you are correct
At least from my point of view, there appears to be a parsing issue with IE8. When the browser encounters .axd script references it sometimes mangles the page content into the URL of the request. The browser then determines that it doesn't have any cached
content for ScriptResource.axd?d=[random-junk] and requests it from the server. You can see this request in IIS logs. Because ASP.NET correctly identifies the request as invalid it returns an appropriate HTTP status code and the response is not parsed as JavaScript.
However, because the mangled request is superfluous to all previously cached requests it doesn't present a problem to your application code. (That is, something failed to load that is not needed and is not referenced.)
Considering what I am proposing here, if IE8 was to generate one of these mangled requests when first visiting a page then yes, it is more than likely that the application code would be affected and the user would notice a problem.
I want to get to the bottom of this too - our application error logs are filling up!
We have seen this thousands of times on our public sites, but only from IE8.
Today we reproduced it by accident on one of our PCs browsing one of our production web sites.
We recorded a packet capture at the network level, and a minidump of the IE8 process.
.NET/IIS is serving up the page correctly, but IE8 is requesting a bogus ScriptResource.axd URL. It's acting as if it ignored 4KB of the HTML when parsing the page.
Interestingly, the correct ScriptResource is already in IE8's cache, View Source shows the correct page, IE8 Dev tools show that all scripts are loaded correctly, and the page works just fine.
If anyone from MSFT wants the packet capture and minidump we can make these available, please email [email address omitted].
JoeVolcano
Member
26 Points
13 Posts
Re: Corrupted WebResource.axd url parameters
May 14, 2009 01:27 AM|LINK
I added the following around my script and I have not scene the issue since. its odd because the google analytics code does not have this around it. the script that does is at the bottom of the page and is the last script in the page and uses JQuery. I dont know why or how this fixed it beacuse I am also not using a XHTML doctype tag. but like I said have not scene it since so.... go figure
<SCRIPT type=text/javascript>
//<![CDATA[
[code]
//]]>
</SCRIPT>
shahed.kazi
All-Star
17953 Points
3635 Posts
Re: Corrupted WebResource.axd url parameters
May 14, 2009 01:52 AM|LINK
You should not worry about the parameters of the axd files. The parameters are generated based on the javascript/ajax you are using,
.NET World |Captcha Control
beska_miltar
0 Points
5 Posts
Re: Corrupted WebResource.axd url parameters
May 14, 2009 03:20 PM|LINK
Normally we wouldn't, but it's generating them incorrectly, and messing things up.
Or at least, so it appears. I'm becoming convinced that .NET is doing its job just fine, and generating the page just fine...and the page is losing text somewhere after that point. For instance, if I look at one of my mangled URLs, all of the text is valid...even the mangled part. It's just that the mangled part is supposed to be much later in my page. If I look at how much text is missing, it's exactly 4k. That, to me, smells fishy. Once I started looking around, I've noticed some other errors that could also be this problem, but are showing up in different areas on the page (not in the middle of webresource.axd) so we were assuming they were different problems.
That might explain why adding CDATA tags "helped" joevolcano out...he could still be getting this issue of dropping 4k of text...but it's no longer starting in the middle of the webresource.axd url, so he doesn't see the same error message. If I'm right, most of the time, in fact, no error will be thrown by this problem, since losing a chunk of text on the client side might cause the text to be missing a big chunk, look funny, etc., but the server would have no way of knowing this had happened.
We've had this issue cropping up with increasing frequency, without having had an overall spike in traffic. This increase seems to coincide with the beta and final releases of IE 8. I combine this with the fact that I've only seen this bug when the client identifies itself as IE 8 or 7 (IE 8 will identify itself as IE 7 if it's in compatibility mode), and this makes me believe that there is a decent chance that IE 8 has some kind of parsing issue that is causing it to drop a memory page somewhere (hence the 4k chunk.)
Now...how to prove it...
matten
Member
4 Points
2 Posts
Re: Corrupted WebResource.axd url parameters
May 14, 2009 03:32 PM|LINK
You´re absolutely right. IE8 somehow tampers the d-Parameter, so that the query for the AXD-resource won´t return any javascript i think. Fortunately the user won´t notice this in all cases. I could reproduce the error by clicking around on our web page very fast, and had those errors with my IP Address in my log files. While clicking around as a user i didn´t notice any problems.
JoeVolcano
Member
26 Points
13 Posts
Re: Corrupted WebResource.axd url parameters
May 14, 2009 03:40 PM|LINK
very interesting. when I was getting the corrupted webresource.axd urls I did not examine the number of bytes between the url and the goofy txt. but they were all over the place so not sure they were exactly 4K though could still be because sometimes the corrupted url was shortened at different lengths. I still have the google analytics javascript in the page. and I am not using the CDATA tags around it. I have not seen any errors since except a "unable to parse viewstate" but very infrequent nothing like the webresource.axd which was occuring every hour. but this site also gets a lot of traffic. I would guess that if there was data being dropped or threads getting crossed when parsing by the client browser, it would cause this issue with the viewstate as well. I am going to put the CDATA tags around the google analytics javascript next. I think you are probably correct that it is an IE8/IE7 compat mode issue. though I cant tell how to see if the browser is in compat mode from the request object.
4K sounds like a buffer size IMHO, infact I think the latest xml parsing objects from MS use a buffer read of CDATA in xml
though my doc type is
<!
DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">not xhtml...
JoeVolcano
Member
26 Points
13 Posts
Re: Corrupted WebResource.axd url parameters
May 14, 2009 03:47 PM|LINK
Personally I am not "worried" about the parameters themselves what I am worried about is getting exceptions in my error log and users inconsistantly getting bad links because there browser cant resolve the javascript because the bad webresource paramaters that you suggest not to "worry" about are present. did you even read the posts here? is this the consistancy of your over 5000 points? contribute something. or at least defend your ambigous opinion so that I can agree with you.
mattbrooks
Member
28 Points
25 Posts
Re: Corrupted WebResource.axd url parameters
May 19, 2009 01:23 PM|LINK
I've contributed to the MS Connect Feedback at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997. This is happening on most of our production sites but NEVER seems to present itself as an error to the user. I've also only seen the issue with IE8 and no other browsers.
Has this issue ever manifested as a problem to the user for anyone - or is it entirely "behind the scenes"?
beska_miltar
0 Points
5 Posts
Re: Corrupted WebResource.axd url parameters
May 19, 2009 01:58 PM|LINK
MattBrooks: How do you know it never shows up as an error to the user? My guess is that it does, but it's usually in somewhat subtle ways. For instance, if the link to WebResource.axd is bad, it won't load in that supporting JavaScript. No error will necessarily be immediately obvious to the user from that problem...but some associated functionality, such as script validation may now fail.
It looks like most people are having problems with 4K being dropped from the html stream somewhere. Can you verify if that's what you're seeing as well?
We are actually seeing this problem in more places than we originally anticipated, but we weren't aware of them because the only time it was reported back to the server was when a url was bad (such as WebResource.axd), and then a request came back for that URL.
mattbrooks
Member
28 Points
25 Posts
Re: Corrupted WebResource.axd url parameters
May 19, 2009 02:25 PM|LINK
Hi Beska,
I have been able to reproduce the issue in our staging and live servers. The behaviour I have observed is the browser always seems to load the .axd resources successfully when it doesn't have them cached, i.e. the first time they are loaded. It is only on subsequent page loads that the mangled requests are generated. I'm not sure why the browser is generating the mangled requests though. It seems to have all scripts loaded successfully from its cache as no functionality is broken. Hence the user never experiences any problem (in fact the user is not even aware of the additional mangled request).
I can confirm that I'm seeing data lost out of the stream. I am unable to confirm that it is exactly 4k but I suspect you are correct
At least from my point of view, there appears to be a parsing issue with IE8. When the browser encounters .axd script references it sometimes mangles the page content into the URL of the request. The browser then determines that it doesn't have any cached content for ScriptResource.axd?d=[random-junk] and requests it from the server. You can see this request in IIS logs. Because ASP.NET correctly identifies the request as invalid it returns an appropriate HTTP status code and the response is not parsed as JavaScript. However, because the mangled request is superfluous to all previously cached requests it doesn't present a problem to your application code. (That is, something failed to load that is not needed and is not referenced.)
Considering what I am proposing here, if IE8 was to generate one of these mangled requests when first visiting a page then yes, it is more than likely that the application code would be affected and the user would notice a problem.
I want to get to the bottom of this too - our application error logs are filling up!
mattbrooks
Member
28 Points
25 Posts
Re: Corrupted WebResource.axd url parameters
May 28, 2009 07:08 AM|LINK
From Connect...