Invalid Webresource.axd parameters being generated

Question

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 invali

Answer 1

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!

Answer 2

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.

Answer 3

This was eventually fixed by Microsoft:

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

Answer 4

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.

Answer 5

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?

Answer 6

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