Invalid Webresource.axd parameters being generated.

Answer 1

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.

Answer 2

I am having the same problem. did you find a solution. buggin the crap out of me!!!

Answer 3

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 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

Having the same problem here http://forums.asp.net/p/1373410/3100520.aspx#3100520

Answer 6

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 7

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