Invalid Webresource.axd parameters being generated

Asked 20/1, 2009 at 14:48 Answered 5/6, 2009 at 19:15

Solved asp.net webresource.axd invalid-url

Original Question:

We have an odd error with WebResource.axd url generation. (It does not seem to be related to the fairly common "WebRsource.axd Padding is invalid and cannot be removed" issue).

We have an ASP.NET web page that, when created, adds a script reference to WebResource.axd.

In this case, we're seeing that the WebResource.axd link occasionally turns into garbage past a certain point, replaced by what looks like javascript. Worse yet, the url generation failure seems to be inconsistant.

In our case, the link should (and usually does look like):

/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&amp;t=633464867255568315

All well and good. However, we are getting errors logged from users...and the url they're trying to access looks like (in one case):

/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......

[the remaining encoded javascript from that link has been removed as irrelevant]

Stranger yet, we got a few of these in rapid succession from the same user, who was apparently trying to reload the page...each url slightly different.

/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>

In some cases the garbage is encoded JavaScript, I've seen portions of a url...completely empty parameter strings...I don't see an obvious pattern.

As an aside, should it be relevant, it should be noted that I don't believe that this WebResource is anything other than a stock WebResource that is automatically included by .NET when certain features are included on a page...in this case, a field validator. Looking at the contents of the actual WebResource.axd reveals very standard looking set of Javascript functions that seem designed to handle generic .NET events. Not anything we've created.

Has anyone seen anything like this? (or better, has anyone understood why this was happening, and come up with a way to eliminate it?)

EDIT 0: Some additional information:

Item 1: In response to one answer, we made sure that our scripts are encased with CDATA tags, since our doctype is xhtml transitional:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Unfortunately, though we had high hopes, it does not seem to have solved the problem. We've noticed this more often with IE 8 as a browser, which would lend some credence to the idea that this is browser related...perhaps the way the browser is parsing the stream...but why we would get subtly different responses on subsequent attempts baffles me.

Item 2: It turns out that the omitted sections seem to be blocks of fairly regular size. Someone reported that he was seeing 1k or 4k blocks missing, and I (so far...I've only looked at two cases thus far) would agree (mine were both missing 4096 bytes of data).

Generalization answered 20/1, 2009 at 14:49 Comment(1)

Update: The 4k bug is now fixed by the IE8 Cumulative update on 3/30/2010. blogs.msdn.com/ieinternals/archive/2010/04/01/… – Pathan 1/4, 2010 at 1:57

This was eventually fixed by Microsoft:

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Generalization answered 20/1, 2009 at 14:49 Comment(0)

according to this post:

http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

It seems that the problem is caused by the way browsers render pages differently when the doctype is not specified.

Here is another interesting post i found on this subject, still not the solution though:

http://blog.aproductofsociety.org/?p=11

on the above page it has "Response.Cache.SetNoStore()" as a possible solution in the comments, i'll try this next to see if it helps.

Mordent answered 4/2, 2009 at 15:3 Comment(13)

Holy macaroni! I'd about given up on this one. I'm going to go try this out now. I'm voting it up now, but if this solves the problem, I'll be wishing I could vote this one up several times. Thanks, either way. – Generalization 4/2, 2009 at 21:23

Argh. No dice. I suspect that this is probably the answer that works for some people, but we're still having the same issue...(though I expect the underlying cause might still be the same...) – Generalization 20/4, 2009 at 18:31

Yeah, we're still having this issue here too, this is something interesting i found blog.aproductofsociety.org/?p=11 – Mordent 20/4, 2009 at 20:37

Bleh. Well, since I'm getting nothing on this so far, you might end up with the 200 rep by default! – Generalization 20/4, 2009 at 21:18

If you would, would you go to connect.microsoft.com/VisualStudio/feedback/…, and rate it highly so that we have an improved chance of getting this issue resolved? – Generalization 24/4, 2009 at 13:55

Hmm...I'm beginning to think that the bounty system has a big flaw...you're going to get the bounty, which is fine, of course...but it's also going to mark this answer as "accepted" which implies that it solved the problem (and, although it's been very useful, it doesn't actually solve the problem.) Seems like a flaw. – Generalization 27/4, 2009 at 17:3

Voted up the connect.microsoft.com thing, i hope an answer to this can be found. – Mordent 27/4, 2009 at 21:12

Are you getting this problem in non-IE 8 situations? The more I look at this (especially considering the leads you've provided), the more I'm thinking that this is related to the way IE 8 is parsing the stream, rather than what is being returned by .NET and the web server. Have you seen this in anything other than IE 8? (I've seen an IE 7, though I'm not sure if it wasn't IE 8 in "compatibility" mode). – Generalization 30/4, 2009 at 13:30

@beska, you're right in that it seems more like an IE8 problem and we have seen it on IE7 too, not on firefox or safari though... maybe it is an IE8 issue and we can leave it at that? – Mordent 30/4, 2009 at 14:13

Hmm. I'd like to do that...but IE 8 is probably going to be here for a while...and telling users "hey, it's not my fault, it's IE!"...true enough, but they don't care. They just want it to work. sigh. – Generalization 30/4, 2009 at 20:3

maybe IE8 will be fixed with a service pack and the issue will be solved. – Mordent 1/5, 2009 at 12:45

Now that would be good. Have you checked how much data is missing? I was looking at someone else that posted about this and he was claiming that he was missing either 1k or 4k of data. So I checked a sample of mine, and sure enough, I was missing exactly 4096 bytes. Not sure what I can do with this information yet...but it's an interesting clue. – Generalization 6/5, 2009 at 13:49

I have checked and I also see exactly 4096 bytes of data missing when this exception occurs. The few times we have been able to replicate this in house it is always using IE8. Sometimes it is in IE7 compatibility mode, sometimes not. – Mccaslin 4/6, 2009 at 16:26

Microsoft has responded to this issue:

Note is a bug in Internet Explorer 8. The Internet Explorer team has been investigating this issue.

-=Impact=- Thus far, we believe the problem has no impact on the end-user's experience with the web application; the only negative effect is the spurious/malformed requests sent by the JavaScript speculative-download engine. When the script is actually needed by the parser, it will properly be downloaded and used at that time.

-=Circumstances=- The spurious-request appears to occur only in certain timing situations, only when a META HTTP-EQUIV tag containing a Content-Type with a CHARSET directive appears in the document, and only when a JavaScript SRC URL spans the 4096th byte of the HTTP response body.

-=Workaround=- Hence, we currently believe this issue can be mitigated by declaring the CHARSET of the page using the HTTP Content-Type header rather than specifying it within the page.

So, rather than putting

[META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"]

In your head tag, instead, send the following HTTP response header:

Content-Type: text/html; charset=utf-8

Note that specification of the charset in the HTTP header results in improved performance in all browsers, because the browser's parsers need not restart parsing from the beginning upon encountering the character set declaration. Furthermore, using the HTTP header helps mitigate certain XSS attack vectors.

NOTE: There have been reports that this problem still happens when the META HTTP-EQUIV is not on the page. We will update this comment when we have more investigation. Posted by Microsoft on 6/30/2009 at 12:25 PM

Mccaslin answered 20/1, 2009 at 14:49 Comment(0)

I am from the ASP.NET team -- we are looking for a customer willing to work with us on researching this issue. If anyone is able to reliably reproduce the problem by requesting their own pages and checking the logs, and is willing to work with our support group, please respond or send me a direct message. Thanks!

Mischiefmaker answered 5/6, 2009 at 19:15 Comment(2)

This was written some time ago, and after considerably more investigation and corroboration with other people having the same issue, it looks like this is, in fact, an IE 8.0 issue. Still, I think I speak for everyone when we say we'd love someone directly involved to give this a look. Is there any good way to bring this issue to the attention of the IE 8 team? The Microsoft Connect forum for IE seems to be closed, and no other obvious avenues come to mind. – Generalization 8/6, 2009 at 13:11

Yes, a good way is to contact me if you are able to provide any repro. The fact I'm from the ASP.NET team doesn't mean the IE8 team isn't involved -- we are using whatever resources we can to figure it out, including IE folks. This connect bug is also a good place to add information: connect.microsoft.com/VisualStudio/feedback/… – Mischiefmaker 16/6, 2009 at 0:15

What version of .NET are you compiling against? What happens if you change your build to build for an older or newer version? (not sure if this would do anything but it's worth a try)

If it's still happening, I think you should post a bug about it on Microsoft Connect. They should come back to you pretty quickly.

Mungo answered 24/4, 2009 at 7:2 Comment(2)

Changing the .NET version: sadly, that's not an option for us... Microsoft Connect: I'll give it a shot! – Generalization 24/4, 2009 at 13:31

I've gotten a response that they (Microsoft Connect) are looking into the issue...hopefully they won't just say "we can't reproduce it" and close it. – Generalization 27/4, 2009 at 17:7

Have you got any HttpHandlers or Modules that are registered in the web config that modify the rendered HTML before it's sent to the user?

These can often be:

Minifiying JS and CSS
Ensure HTML is valid

Might be worth a look.

Beginner answered 24/4, 2009 at 8:25 Comment(1)

Good thought, but I'm 95% sure the answer is no. But I'll definitely ask around to double check. – Generalization 24/4, 2009 at 13:30

This was eventually fixed by Microsoft:

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Generalization answered 20/1, 2009 at 14:49 Comment(0)

This is an old post... but I've came across through a google search and reminded me of this...

http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html

Could it have been related?

Mantelet answered 20/1, 2009 at 14:49 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags