Home Dashboard Directory Help
Search

Invalid Webresource.axd parameters being generated by Beska Miltar


Status: 

Closed
 as Postponed Help for as Postponed


205
1
Sign in
to vote
Type: Bug
ID: 434997
Opened: 4/24/2009 6:49:38 AM
Access Restriction: Public
4
Workaround(s)
view
171
User(s) can reproduce this bug

Description

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&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?)

Some additional information...in response to some research, 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.

EDIT: After looking around, we're seeing indications that this is a more widespread problem than we had initially anticipated. We were seeing this manifest itself within the WebResource.axd link because the user was trying to access that invalid URL, and so that error was logged within our web server...but now we're seeing some indications that this may be happening in many places, and we only are seeing indications of the problem when the mangling happens to start within a URL...because only then will a request potentially be made back to the server with that bad URL.

Comments made by people below have allowed us to narrow in on some of the aspects of the problem: The URL isn't just mangled...what is actually happening is a section of text is lost. The URL may start fine, but then 4K of the html is missing, which means the rest of the url is whatever is in the page 4K later.

Again, we noticed this initially because we were getting errors on the server when clients were requesting WebResrouce.axd with bad parameters, but after looking around I suspect that this is happening in other places as well, and being logged in different places...for example, we are seeing errors where the URL is too long...and it looks like the URL being requested starts correctly again, but then jumps into the ViewState. Different looking error, but with the same problem...4K being dropped.

Now, I strongly suspect that this is related to IE 8. We first started noticing this when the IE beta came out, and it has increased steadily ever since. I've also spoken with people who claim that that they've been able to reproduce the problem, but only with IE 8. (We see some reports with IE 7, which we suspect is actually IE 8 in "compatibility mode")

Details
Sign in to post a comment.
Posted by Wegel on 5/10/2012 at 2:10 AM
I got the same issue with IE9 ( havent checked for older IE). I've tested it on Chrome, FF and Safari and none has gotten this error.
My Set up is that I have an error trapping to send emails and redirect the user to a page. I only get the error for IE9.

In my case, because it happened in IE9 and that I was forcing a redirect to a default page, the normal workflow broke for all IE9 users. So I tried skipping the redirect page when I got this specific error, cleared the errro and I was able to go back into the normal work flow . After I disabled the redirect (only for this type of error) It does not seem to have any impact on user experience as far as I can see... I use a lot of AJAX and Telerik COntrols on my page.

Am I the only one getting this in IE9 ( although it seems someone from MS claimed it was fixed in IE8?)

Thanks
Posted by tomysmile on 11/15/2011 at 3:05 AM
Got the same issue and being throws as This is an invalid script resource request, Void Throw404(). As if the ASPNET engine was not rendered the script completely.

So far the issue happened only with /ScriptResource.axd. Any thought ?
Posted by phuff34 on 1/17/2011 at 2:10 PM
We're receiving this issue but we have users using Firefox and getting this. It is not just in IE8.
Posted by kopkop on 11/11/2010 at 6:58 AM
To IE team and other user who encounter this problem :

Hello,
I am really aware of this problem and tried all the possible solutions described everywhere on the net. All our configurations are configured well.
I did not find the solution of the problem but I found a strange behavior when I obtain ' sys is undefined ' with IE8.
I have on my computer an emulator (IE tester to name it). If I go on the page where my error ' sys is undefined ' occurs, with IE tester while emulating IE8, the error does not appear. If I refresh the page where the error ' sys is undefined ' occurs on my real browser of Internet explorer 8, the error disappears. So all other users who obtained the error on their respective computer are free from this error.
But the error can come back later. Going back with IE tester emulator IE8 on the page in error, the error disappears every time.
I wanted to note this point because nobody had raised this situation after very long researches on the net on this subject.

Could anybody help us?


À l'équipe de IE et tout les utilisateurs qui rencontrent ce problème :

Bonjour,
je suis vraiment conscient de ce problème et j’ai essayé toutes les solutions possibles qui on été décrites partout sur le net. Toutes nos configurations sont adéquoites.
Je n'ai pas trouvé la solution à ce problème mais j'ai trouvé un étrange comportement lorsque j'obtiens 'sys is undefined' avec IE8.
J'ai sur mon poste un émulateur (IE tester) pour le nommer. Si je me rend sur la page où mon erreur 'sys is undefined' se produit, avec IE tester émulant IE8, l'erreur n'apparaît pas. Si je rafraichit la page où l'erreur 'sys is undefined' se produit sur mon vrai navigateur internet explorer 8 se produisait, l'erreur disparaît. Aussi tous les autres usagers qui obtenaient l'erreur sur leurs postes respectifs se retrouvent libérés de cette erreur.
Mais l'erreur peut revenir plus tard et ainsi on retournant avec IE tester qui émule IE8 sur la page en erreur, l'erreur disparaît à chaque fois.
Je voulais noter ce point car personne n’avait relevé cette situation après de très longues recherches sur le net à ce sujet.

Est-ce que quelqu’un pourrait nous éclairer ?
Posted by P.Huhn on 11/5/2010 at 9:02 AM
Hi:
It was stated by EricLaw [MSFT]:
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

I am not sure exactly what the work-around is. It seems that prior to any asp.net/ajax code is sent, one has to define the content type. So, that means one is using either web.config or IIS to set the content type.
I have in test server created via the IIS admin a HTTP reponse header:
    Name: X-Content-Type
    Value: Content-Type: text/html; charset=utf-8
In Fiddler the X-Content-Type is seen in the misc tree. Is this a work-around?
Phil
Posted by felickz on 10/28/2010 at 10:25 AM
From "07/08/2009" --

-=Future=-
The IE team will continue our investigation into this issue and may elect to make available an update for IE8 to correct this problem.


Is there any IE8 patch that fixes this yet?
Posted by idbelkhayat on 10/20/2010 at 2:06 AM
Le bug n'apparait pas aussi sur Opera.
Posted by idbelkhayat on 10/20/2010 at 2:06 AM
Bonjour,

J'ai le même souci, le bug est reproduit aussi sur safari/Google chrome (version windows xp/Seven). donc je pense que ce n'est pas forcement lié à IE8. il est reproduit aussi sur windows seven. le bug n'apparait pas sur firefox.

J'ai un système de compression activé. je l'ai enlevé pour pouvoir identifier le bug. le bug est resté.

La solution :
<httpHandlers>
     <add verb="GET" path="WebResource.axd" type="System.Web.Handlers.AssemblyResourceLoader" validate="true" />

n'a pas corrigé le bug.

Ni cette solution :

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

Mon site de dev est le suivant : www.mibesys.com/modules.html

Login : Anonyme.
Passe : anonyme.

Merci de vérifier par vous même.
Pouvez vous me fournir une solution.

Cordialement.



Posted by FSM.LIVE on 10/5/2010 at 5:01 AM
I also got the same problem, but when I register 'webresource.axd' in web.config the problem is little bit fixed:

<system.web>
...
<httpHandlers>
     <add verb="GET" path="WebResource.axd" type="System.Web.Handlers.AssemblyResourceLoader" validate="true" />
     <add verb="*" ... />
</httpHandlers>
...
</system.web>
Posted by Nikolay Grishaev on 8/26/2010 at 2:58 AM
My pages do not have <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
But web site log contains report about this exception every day.
Posted by foux on 6/15/2010 at 5:21 AM
We can reproduce this bug in IE7:

Page Call:
GET/https://mywebsite.com/WebResource.axd?d=CErUQeC_NfjkvB72N6QLt9h7lzOdaHwxw%2frEaZvKQBdI%2fk16birUO0WtEnCYzWP353cQoO1ggS2DfD0QX9649EfO6NrHNaOyVr6GW8DK011XrrTeitdjI22NSzmGCRxAeMu078Rt7m4Uh7QMfHwAUO44BaIIxFHysop%2fDehLQz7jxAqhihD0C5A%3d');

URL Stack:
/WebResource.axd
        d=CErUQeC_NfjkvB72N6QLt9h7lzOdaHwxw/rEaZvKQBdI/k16birUO0WtEnCYzWP353cQoO1ggS2DfD0QX9649EfO6NrHNaOyVr6GW8DK011XrrTeitdjI22NSzmGCRxAeMu078Rt7m4Uh7QMfHwAUO44BaIIxFHysop/DehLQz7jxAqhihD0C5A=');

Server Info
Host:         ---
Name:         ---
Soft:         Microsoft-IIS/6.0
User:        

Client Info
Host:                 ---
Soft:                 Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
User:                 ---

Stack Trace:
[HttpException: Invalid viewstate.]
at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Posted by Luiz O U Vianna on 5/18/2010 at 6:11 AM
Anyone have found a solution?

I´m facing this too and I see here that this issue is being on discution for more than a year now.

For people like us that has a lot of web users and an agent that alerts when a error occurs, the amount of alerts could drive anyone crazy....

Regards
Posted by Unregistered User on 4/16/2010 at 5:16 PM
*
Posted by Borgy3377 on 3/18/2010 at 6:03 PM
I can't believe this problem is still hanging around. We are also considering moving to FireFox.
Posted by Don MacKenzie on 3/18/2010 at 1:41 PM
In all seriousness, we are considering telling our user base to switch to Firefox.
Posted by webdevdude on 3/15/2010 at 7:42 AM
I disagree with the IE team that there is no impact on the end-user's experience. This problem is causing the MS AJAX client framework load to fail in my web app when accessing it via IE8. Consequently, I lose all functions I leveraged from the AJAX toolkit (TabContainer, Masked validation....), which is forcing me to discontinue using the toolkit and write custom JS. I have lost time on a time-critical project and my client doesn't really care if I use the toolkit or something else for client side functions. See error details (URL modified to protect client confidentiality) below:

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.4; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 1.1.4322; MS-RTC LM 8; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Timestamp: Mon, 15 Mar 2010 14:34:10 UTC

Message: Invalid character
Line: 1
Char: 1
Code: 0
URI: http://testclient.com/Website/ScriptResource.axd?d=yOFdUXaIZdjTwQKX6eX4TGVGWj5SlmEa0qNtZ-UXtuz1utWUhnP6z8hddNZQE_4U0&t=5fbf692

I was using AJAX toolkit v3.0.31106.0, which is accessed via ScriptResource.axd.
Posted by Neilski on 3/15/2010 at 2:36 AM
I've been watching this post for a while now and have so far resisted commenting as it is too easy to cloud/confuse the issue with particular instance issues. Having said that, we now have around 30 web sites running our content management system. Ostensibly these are all bulkt on the same codeline and are running in the same hosting environment, i.e. apart from instance specific configurations they are all 'similar' in their technology. The stange thing is that around eight of these sites show this error while the rest don't.

Firstly I don't think adding/removing the meta data stement makes any difference. What I do think makes a difference is the number of client script inclusion statements (<script> statements with a 'src' attribute) in the head of the page and also the amount of script volume referenced by those inclusions. I suspect that the issue is a factor of client script volume against number of client script references, but I can't be sure.

What I can be sure of is that the sites showing the error all reference at least six external script references with a total byte count of over 200k. I also have a hunch(!) that the connection speed/transfer rate may be a third component. The only reason I say this is that we have a couple of customers in New Zealand and they experience this problem to a much greater extent than more local connections - the only reason I can think of for this would be the connection latency. See below.

Empirically I have found that either reducing the number of client script references and/or combining them reduces the error rate significantly. I have been experimenting with dynamically combining and compressing (gzip) with good results.

These influences may, of course, be peculiar to our development, but I would be interested in knowing what client script profile other people experiencing these problems are using and whether there is a correlation.

Finally, I would add that I'm also not 100% sure that the statement "has no impact on the end-user's experience" is actually correct as we have received some reliable reports that the page appears to be empty when downloaded. On investigation the page source file appears to be truncated at, or near, the opening body tag. Since we have now way of regularly reproducing the problem, I cannot confirm this.
Posted by Chris 2 on 3/9/2010 at 6:42 AM
We recently experienced this on a page in IE 8. Interesting observations:

We're not using META tags, the content-type is coming from the header.
The WebResource.axd request is cut off at the ~14284th byte; then ~4111 bytes are cut out and the random stuff that comes after that is inserted into the URL. So this can happen even when it's not at the 4096th byte!
We added ~4105 bytes of padding before the doctype, in an attempt to stop this from happening, but it didn't work.
Posted by mike_from_holland on 2/26/2010 at 8:29 AM
Dear MS,

Customers are asking about why our application causes this error. The only thing we can tell them is that MS is working on the issue, however, this is getting very old since it has been going on so long. Finally, when the fix is delivered, customers will need to have the latest IE patches installed for it to officially go away. Even after the fix, it will take months for the errors to finally subside. It is unbelieve that it has taken this long just to punt this issue around when their are thousands of servers around the world getting this bogus event log warning. Event logs entries and exceptions = increased server I/O + decreased perforamnce + support calls to vendors. This issue is costing others time and money and it needs to fixed ASAP.

Why in the world can't you fix this bug in ASP.NET as well as in IE8? The exceptions are raised on the server by the framework. Why can't we just get a fix that stops the error from displaying in the app event log? Is there another workaround for achieving this? My needs are simple...
Posted by Adrian Ocaña on 2/22/2010 at 9:46 AM
Could this happen only in certain situations such as google indexing? Or is random?

Thanks in advance.
Posted by ch12345 on 2/11/2010 at 7:28 AM
Microsoft: when will this be fixed? This error is out of control. Whether the issue is with IE or with Asp.net, please take responsibility as a company and get this corrected. This looks very, very bad.
Posted by SamarJeet Singh on 2/3/2010 at 1:45 AM
I am also facing this type of error in my website and unable to find solution.some one says that it is bug of IE8.could any body tell me what is the solution of this fallowing error

Error Page : http://mywebsite.com/ScriptResource.axd?d=uWsQnC017-OzE1SULgory'); } function
                 PostBackTypeFilter (aId) { var blnFilter = getCheckedCheckboxesCount(aId); ASPxPopCtrlFltType.Hide
                 (); if (blnFilter == true) { document.getElementById(

Error Message : Invalid viewstate.

Error Destination : System.String DecryptStringWithIV(System.String, System.Web.Configuration.IVType)
Posted by ChrisWuestefeld on 1/21/2010 at 6:17 AM
Dear Microsoft: since you indicate that you're closing this bug on the ASP.Net side and transferring it to the IE team -- yet it's 3 months later with no apparent fix, can you provide a link to the corresponding IE bug for us to follow up with?
Posted by Microsoft on 10/12/2009 at 11:15 AM
We are closing this bug on the ASP.NET side because it is not an ASP.NET bug but instead is a bug with the IE 8 having issues with certain size buffer boundries. The various workarounds that people have submitted are just changing the size of data (when in the stream headers are hit) which cause the effects to change. I want to note that this bug is being fixed on the IE side and we will come and update this connect bug when that happens.
Posted by David Keaveny on 10/5/2009 at 10:54 PM
Silly question - where do we set the HTTP Response Header? (This is in IIS7). Globally in the IIS admin tool in the HTTP Response Header, or by playing with the MIME Types, or what? And if we have charset set in-page with an HTTP-EQUIV, should we remove all references to it once the server-side change has been made?
Posted by Shadowmoth on 10/5/2009 at 8:14 AM
Any news on the current progress for a fix?
Posted by EmuDesign on 9/27/2009 at 9:55 PM
We tried the given workarounds (added a Content-Type: text/html; charset=utf-8 to the MIME Type .aspx for the website domains under IIS), but that didn't seem to help. Should we be adding one under .axd as well or am I misunderstanding the instructions?
Posted by Aim12345 on 8/27/2009 at 3:11 AM
We can see this error very often. The user-agent is always IE8.

The suggested workaround doesn't help because we don't have META HTTP-EQUIV="Content-Type" tag on the page, we already send the right content type in HTTP response.

Example of errorneous URL:
/ScriptResource.axd?d=CjPWmBF5qjpMPmo7qkw1wMxy6J3IeG43GxgbQUsvFEjsip14I2Dwy4St58Eyvuo2Z4yanh3Hh5faO1LQ5lk0DlGh91Ey23kcQtrda0-dq8I7O0Wxaqlu3mP_TaF-fsCZ-zgmxKiryqPpmwN8XnYNrlZBhFomNi3kpJMYu2Nv6nOmRK2kFLyiDPZTQAQKNjYH5AwLHutHPBwKDzPDQAQL4uunPBwKFzPzQAQKpl9z7CgL6uunPBwKzmYORDQL39+2QAwLkxOnRDgKrl+j7CgLlxMXRDgLO7bqNDALlxJ3QDgLlxKnQDgLas7bPBALmxJnQDgLR8qWmAwLnxMXRDgLpxNnRDgLAuvnPBwLBuunPBwL+982QAwKl6tDhCAK46tDhCAK56tDhCAK66tDhCAK76tDhCAK/6tDhCAK86tDhCHrJW2uRVOtl80zOjfRQ3vud5Vkf

User-Agent:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.1; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
Posted by Jordan Rieger on 8/25/2009 at 1:54 PM
We first started seeing this in our site error logs on 2009-08-01. For us, it affects normal .ASPX, and the erroneous URL's being loaded are not .AXD's. Of course our users are not impacted, other than their wasted bandwidth (and ours.)

I would like to see this fixed in an IE8 update soon because, from Microsoft's technical analysis, it sounds like something that might indicate a latent buffer-overflow vulnerability -- crossing page boundaries, incorrect parsing, etc.

Jordan Rieger
Software Developer
Ripe B2B Inc. for Webnames.ca Inc.
Posted by Helephant on 8/25/2009 at 3:38 AM
I had the same problem when I was viewing my own ASP.NET website through IE8. Once I started having the problem, I saw the error on a number of different pages across two different sites on two different ports.

I was doing something a bit unusual when it happened so it might be related:
1. I had two separate pages of the same website open in unauthenticated mode
2. Logged into the website using one of the tabs
3. Reloaded the second tab

It didn't just create an entry it the error log, it prevented the website being shown at all. I got a yellow error screen that said: System.Security.Cryptography.CryptographicException: Length of the data to decrypt is invalid.

I fixed the problem in my IE8 by deleting all the temporary internet files. Once I did that, it started working fine. This only affected IE. I tried the pages in Firefox and they worked fine.

I'm running IE8 on Server 2003.
Posted by JamieSnell on 8/13/2009 at 7:44 AM
Two weeks ago I was getting this error many times a day, then we upgraded to a new webserver, and they all stopped. I don't know if it was because of a windows update that was applied to the new webserver that wasn't applied to the old web server.
Posted by Paul Tebbutt on 8/3/2009 at 9:56 AM
We're also seeing this error across all our sites. It's only happening with IE8 and the best tips for reproducing the bug are on this page http://stackoverflow.com/questions/728513/erratic-invalid-viewstate-issue-in-net-application
Especially using Net Limiter to limit IE bandwidth down to 1kb. This generates the error more often.

Is there any update on this bug from the IE8 team? Is there any way we can escalate this through a support incident?
Posted by hhoang on 7/23/2009 at 7:47 AM
I am trying to implement the work around for our site. We get so many errors and it's out of control.

My masterpage already has this line:

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

But you suggested that:

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

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

What do you mean by this? can you include some code?

Also, do I need to remove the META above from my masterpage?



Posted by brad_back on 7/20/2009 at 5:51 AM
What else could cause parser restarts? We encounter this issue, but do not specify the content type of our pages via meta tags. The content-type is specified in the response header (like suggested in the work-around), so something else must be causing the parser restart, but I have no idea what that would be.
Posted by EricLaw-(Ex-MSFT) on 7/8/2009 at 5:33 PM
Hi, Eric Lawrence from the Internet Explorer team here. The Internet Explorer team has been investigating this issue and has constructed a reliable repro which mimics the obscure set of factors needed to cause this problem in IE8.

It is worth mentioning that anyone who is experiencing a problem here in IE6/IE7 or Firefox is encountering a different problem that is not related to the IE8 issue described below.

-=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 the pre-parser is forced to restart (as 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=-
We believe this issue can be mitigated by avoiding constructs that cause a restart of the parser. The most common cause of restarts is specification of the CHARSET in a META tag. (There are other, more obscure causes of restarts, but the CHARSET is believed to be the most common).

By declaring the CHARSET of the page using the HTTP Content-Type header rather than specifying it within the page, you can remove one cause of parser restarts.

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.

-=Future=-
The IE team will continue our investigation into this issue and may elect to make available an update for IE8 to correct this problem.

thanks!
Posted by Greg Balajewicz on 7/2/2009 at 2:46 PM
Correction to my comment. This seems to occur to IE8 only. IE8 running in compatibilty mode looks like IE7 to the webserver
Posted by Greg Balajewicz on 7/2/2009 at 2:05 PM
We are getting around a 1000 error like this daily. Took a while to track down. It is happening with IE7 and IE8 (or least this is what it appears. we've seen some from what appears to be IE8 running as ie6 - probably compatibility note). Not sure if the instances of ie7 are also ie8
Posted by Microsoft on 6/30/2009 at 12:25 PM
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 freecellwizard on 6/25/2009 at 12:36 PM
I'm seeing this problem with a small public site we use to share documents. I have a global error handler in global.asax that logs every error to a central table. I got like 70 Invalid Viewstate errors today and various others in the last couple of weeks. Every single one is for scriptresource.axd and almst all have IE 8 as the user agent. I would expect users of this site to be mostly IE users.

The exact browser configuration/OS varies. The various combinations (note there are zero for IE7, and I had only 2 out of hundreds that were IE6 ... the rest are IE8):

HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6; .NET CLR 2.0.50727; .NET CLR 1.1.4322
HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.2
HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618
HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729
HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1

Posted by Rohland on 6/23/2009 at 2:37 AM
I can confirm we are recieving the same exception. Except the endpoint affected is the scriptresource.axd file. I can only get it to reproduce with IE8.
Posted by FremyCompany on 6/22/2009 at 4:02 AM
<<

    Bug repported to the IETeam :
    https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=467062

>>
Posted by dmarcj on 6/19/2009 at 3:01 PM
I'm also having this issue and I'm very relieved I found this page with others experiencing the same problem.
Posted by Beska Miltar on 6/11/2009 at 8:10 AM
At this point, after research and looking at the large number of user comments, both on this page and elsewhere, I am convinced that this is a problem with IE 8 occasionally dropping 4K sections (memory pages?) of returned html. If so this is a *big* problem. Unfortunately, I don't see a way to post this to the IE 8 team. Ideas?
Posted by bot121 on 6/10/2009 at 11:00 AM
We are getting this error too, it seems to occur most often in IE8.

in the log file it appears as "GET /WebResource.axd d=uNcwKqrfjIH4F8Q2YoWRbw2 <a%20onclick= 80 - "

on the page html its "WebResource.axd?d=uNcwKqrfjIH4F8Q2YoWRbw2&t=633739885393582448"

Isn't the "&t=" another bug too since I assume they are using 't' for timestamp.
Posted by duran_dal on 6/4/2009 at 1:36 AM
Just a quick note.

If you want to be sure that the web browser is really IE8, look for "Trident/4.0" in the UserAgent string. Even if IE8 is in compatibility mode and reports itself as IE7, it will insert Trident/4.0 in the UA string.
Posted by duran_dal on 6/3/2009 at 1:03 PM
We have a CMS in which we use the AjaxExtensions and we have also been seeing quite a lot of Invalid Viewstate errors.

Some browser statistics over a 24h period:

IE6 = 12%, IE7 = 59%, IE8 = 13%, FF = 14% and other = 2%

Invalid Viewstate messages is only caused by IE8 (in our system) and only in 10% of all IE8s (so, a bit more than 1% of our customers get this error).

It shows up in both my Log4Net logs and in the EventViewer. And every single time, the ScriptResource.axd or WebResource.axd request url is garbled and some part of the page's markup is inserted at the end.

I've been trying to reproduce the error for 4 weeks now and I've managed twice... both times I got it when I was furiously clicking on ajax components and not letting them finish loading before sending a new request.
Posted by ChrisWuestefeld on 5/27/2009 at 9:18 AM
Just a quick "me too". We're seeing quite a bit of this. I agree that it may also be affecting cookies, because we're seeing a goodly amount of corrupted cookie data as well.
Posted by SueDOC on 5/25/2009 at 10:03 PM
We have been experiencing the same (or similar) problems with our web application. It occurs with IE8, when the browser is running on a PC with XP SP3. Testing has proven that it does not happen with IE8 on XP SP2, nor IE7 with XP SP3, which seems significant.
The problem is intermittent, but occurs often enough to be easily reproducible. It does not happen with FF3.0 on the same PCs that have the issue with IE8. We have yet to test if it is reproducible with Vista, but at present there is nothing to suggest that it is (based on logging and contacting site users).

We get a number of different errors, all on different pages - never always the same error at the same place:
This is an invalid webresource request (/WebResource.axd)
Invalid ViewState (/ScriptResource.axd and /WebResource.axd)
Invalid character in a Base-64 string (/WebResource.axd)
This is an invalid script resource request (/ScriptResource.axd)
Posted by Matt___B on 5/20/2009 at 1:30 AM
I think we are in agreement that we seem to be faced with an IE8 parsing problem. I also agree with you that IE8 doesn't care about *.axd files in particular. I thought that this might be a parsing problem triggered by something specific to the *.axd, such as encoding, compression perhaps? However, another variation of the error has cropped up in our logs - a request for an ASPX page:

A potentially dangerous Request.QueryString value was detected from the client (_TSM_CombinedScripts_="...         <span id=").
at ASP.secure_deallibrary_default_aspx.ProcessRequest(HttpContext context) +4

The error was triggered by one of our developers just using the application, so it was not malicious. So this is another example of a request mangled with page content. I have still not seen this affect the user experience whatsoever, nor have we had any support requests from any users regarding broken pages.
Posted by Beska Miltar on 5/19/2009 at 10:20 AM
The problem with it being only on *.axd files is that IE 8 shouldn't (and probably doesn't) care one whit about what on earth an axd file is, or how it's different or not from any other kind of file. It's just another url string that refers to some content on the server...it's just a key to pass to the server, and the server can worry about how to handle it, and what to return. I can't believe that the parser is doing something strange looking for .axd files, when they could just as easily have any other suffix and must still work in the exact same way. So if it really is an IE 8 issue exclusively (which it really seems like it is), I think it's got to be unrelated to the fact that we're seeing it a lot in .axd file references. Again, I think this is consistent because most of the time, if it was elsewhere, we'd never know that there was a problem.

As an example, related to my previous comment, I went to our systems guy to see if he'd heard anything about this, and he said no, but he was worried about two different types of error that had cropped up. I looked at them, and they were totally different...he was having problems with invalid cookies and urls that were getting flagged by the firewall because they were too long.

But then when I thought about it, and looked closer at the errors, I realized that the cookie problem could be happening if the 4K chunk started going missing inside the header. There wasn't an easy way to see if that was really what was happening...but for the other one, where the urls were too long...they were urls that suddenly turned into garbage...but viewstate-like garbage. In this case (if I'm right) the missing 4K chunk is starting in the midst of this url, and then ends in the middle of the viewstate. So the URL looks like "myImage.jFGl6mr<lots of viewstate>"

My suspicion is that we're both on this page because this is where we're happening to see this bug, because of our particular systems...but that there are plenty of other people out there that are having this same issue manifesting in different ways, but they don't know to come to this page, for example, because it doesn't look like the same issue, and has different symptoms.

(of course, much of this is educated guesswork....ymmv)
Posted by Beska Miltar on 5/19/2009 at 10:03 AM
> Secondly, your theory that it is only by chance happening for
> *.axd files probably isn't true because we're seeing it across
> different ASP.NET applications deployed to our staging and
> live servers. These all have different content leading up to
> the SCRIPT tags.

Different content, sure...but a different length of content? My guess is like the anthropic principle...it looks like *.axd, because that's all we're seeing. But 95% of the time, if it was elsewhere, we wouldn't see it, because it would be messed up, with 4K gone, but no error would be returned to the server (so nothing would be in the IIS logs) The only time you'd see an error in the IIS logs would be if the messup started inside an automatically loaded url (such as an image tag, a js file...or an *.axd resource). If it was just blowing away a lot of the page, you'd never necessarily know it by looking at the IIS log.
Posted by Matt___B on 5/19/2009 at 7:36 AM
Beska,

I can only confirm that I am only seeing this behaviour triggered by IE8; running on Vista and requesting *.axd resources (namely WebResource.axd and ScriptResource.axd).

The concern that it might be happening for all sorts of requests is unlikely because I have seen no evidence of it in our IIS logs. I can only comment on what I have observed though. Secondly, your theory that it is only by chance happening for *.axd files probably isn't true because we're seeing it across different ASP.NET applications deployed to our staging and live servers. These all have different content leading up to the SCRIPT tags.
Posted by Beska Miltar on 5/19/2009 at 6:34 AM
MattBrooks: Are you sure it only happens when requesting WebResource.axd files? That's what I intially thought as well, but now I'm suspecting that it's happening in other places as well for us. We would see it as an error on the server when the user requested the invalid WebResource.axd...but of course, if it happened in another spot, then we simply wouldn't see the error. It turns out when we looked closer, we found indications of additional errors. I suspect that we are seeing ours in the WebResource.axd most of the time because it happens at a particular point in our page. If you're seeing it there *all* the time, it may be that the html leading up to that WebResource.axd is always of a particular length.

I wouldn't expect to see Javascript errors as you describe until the functions that are being called are actually called, and they're not there. WebResource.axd tends to hold things like validation functionality...so have you tried triggering validation after you have gotten a bad page? You might be more likely to see the JS error you're expecting then.

Posted by M_Brooks on 5/19/2009 at 6:13 AM
The last sentence in my previous post should read:

"For some reason the problem NEVER seems to fire when Fiddler2 is logging requests. This makes proving my suspicions difficult!"
Posted by M_Brooks on 5/19/2009 at 6:11 AM
The problem occurs only when requesting script resources (*.axd files). However, the user is never aware of the problem. For example, you would expect JavaScript errors to occur in the browser but full functionality is maintained at all times. Also, the errors never occur during the FIRST request for a given resource. Errors only occur when these resources are loaded from the browser cache. This implies that perhaps an additional and unnecessary request is being sent to the server that does not interfere with the current page code. I infer this because the page obviously has all script resources loaded, either successfully from the server or from the browser cache or the page would not work correctly.

I suspect there is a problem with the parsing engine in IE8 that only becomes apparent when parsing a page where most *.axd resources are loaded from the cache.

For some reason the problem NEVER seems to file when Fiddler2 is logging requests. This makes proving my suspicions difficult!
Posted by Andreas Paulsson on 5/9/2009 at 11:38 AM
We also have this issue, sample url:s are (from today):

WebResource.axd?d=ANpdqNBxu9cts_tvwProducts_UL
ScriptResource.axd?d=RrWPviTovGhlss=
ScriptResource.axd?d=RrWPviTovGhlTKqlyht_jEYmJiJ1iew-Root AspNet-TreeView-Leaf Raw
WebResource.axd?d=ANmnuProducts_tvwProducts_UL

If I view the page that references the resource, I can contruct this url if I remove 4K from the document starting a few character after ".axd?d=".

I have only seen it on IE so far.

We are also using XHTML Transitional doctype.
Posted by runner2557 on 5/8/2009 at 6:49 AM
Here is a error on IE7 WinNT
IsNewSession: ''False''; Type = ''IE7'' ; Name = ''IE'' ; Version = ''7.0'' ; Major Version = ''7'' ; Minor Version = ''0'' ; Platform = ''WinNT'' ; Is Beta = ''False'' ; Is Crawler = ''False'' ; Is AOL = ''False'' ; Is Win16 = ''False'' ; Is Win32 = ''True'' ; Supports Frames = ''True'' ; Supports Tables = ''True'' ; Supports Cookies = ''True'' ; Supports VB Script = ''True'' ; Supports JavaScript = ''True'' ; Supports Java Applets = ''True'' ; CDF = ''False'' ;

"WebResource.axd?d=t6XQ9u7gX40o_T9R0i61j/skinLight.gif''; Referer: ''/Default.aspx'';

Here is one from IE7 WinXP - I cant tell if its in compatibiliy mode

IsNewSession: ''False''; Type = ''IE7'' ; Name = ''IE'' ; Version = ''7.0'' ; Major Version = ''7'' ; Minor Version = ''0'' ; Platform = ''WinXP'' ; Is Beta = ''False'' ; Is Crawler = ''False'' ; Is AOL = ''False'' ; Is Win16 = ''False'' ; Is Win32 = ''True'' ; Supports Frames = ''True'' ; Supports Tables = ''True'' ; Supports Cookies = ''True'' ; Supports VB Script = ''True'' ; Supports JavaScript = ''True'' ; Supports Java Applets = ''True'' ; CDF = ''False'' ;

"WebResource.axd?d=t6XQ9u7gX.ar15.com/biz/engine/showHTML.html?zid=1''; Referer: ''/Default.aspx'';

I am going to install IE8 and see if I get it.
Posted by runner2557 on 5/8/2009 at 6:43 AM
I beleive the reason the frequency is so high with IE in general is just because more people use it. I know in my site its around 90% or more of the users hitting the site are using IE
Posted by runner2557 on 5/8/2009 at 6:41 AM
it occurs at most every hour but we get a lot of traffic.
Here are a few example urls
"WebResource.axd?d=t6XQ9u7gX40o_T9R0i61jAbiz/engine/showHTML.html?zid=1''
"WebResource.axd?d=t6XQ9u7gX40o_T9R0i61%20Account</a></div>%20%20%20%20%20%20%20%20<div%20class="
Posted by Beska Miltar on 5/7/2009 at 7:26 AM
My theory, at this point (which I'm trying to find a way to test) is that the web server is correctly sending out all of the data in the byte stream...and that the browser, IE 8, has a problem, and drops a memory page (4k) of it under some conditions. This would explain why we're seeing this an increase in this issue now under IE 8 (IE 7 shows up when the user is using IE 8 in "compatibility mode").

I'm a bit worried about this theory, however, since apparently some people have reported seeing this "occassionally" with IE 6 or FF 3...these tend to be outliers, and could be just different problems with similar symptoms, but if it's really the same thing on those browsers, that would blow my theory out of the water. Still, I don't have a better idea at this point.

One other idea I've had is perhaps a relatively recent service pack to on the server is causing problems with the data being served to the clients, dropping the occasional 4KB. The problem with this theory is that it doesn't explain the great preponderance of the errors on IE 8, and the lack of them on other client browsers.
Posted by runner2557 on 5/6/2009 at 11:04 AM
its almost as if the object creating the url is not thread safe and as multiple requests are made to the page that renders that url "ClientScriptManager..::.GetWebResourceUrl " it creates a bad url. I love how microsoft never tests anything in the real world for real enterprise systems that have load and multiple threads and servers. There stuff is all great . . . . Theoreticaly .......... if run in an incubator.......thanks.......help us!!!!
Posted by Beska Miltar on 5/6/2009 at 8:16 AM
Facinating. The one I just checked is missing exactly 4KB as well.
Posted by Dan Squier on 5/6/2009 at 5:18 AM
I'm also having this issue - all the occurrences I've logged record an IE7/8 client running on Vista (or occasionally FF3.0), and seem to involve a block of either 1 or 4 KB (always starting within the AXD link) being dropped from the response stream. Any help with this problem would be much appreciated.
Posted by runner2557 on 4/30/2009 at 1:53 PM
I am having this issue as well IE 6,7,8 I have seen it on its sparatic.
I am using <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
been posting here
http://forums.asp.net/p/1373410/3100520.aspx#3100520
Posted by John Boker on 4/30/2009 at 7:15 AM
same issue here, more information on this specific issue can be found at:

http://stackoverflow.com/questions/461605/invalid-webresource-axd-parameters-being-generated
Posted by Beska Miltar on 4/29/2009 at 11:27 AM
I'm not clear on exactly what this means...does this mean that someone is still investigating this and that I should keep looking back here for information, is this considered resolved?
Posted by Microsoft on 4/27/2009 at 2:33 AM
Thanks for reporting this issue. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by EricLaw [ex-MSFT] on 2/3/2011 at 3:06 PM
The IE team fixed this issue in March 2010 via KB980182. Please see http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
Posted by Unregistered User on 4/16/2010 at 5:15 PM
*
Posted by EricLaw-(Ex-MSFT) on 7/8/2009 at 5:33 PM
Hi, Eric Lawrence from the Internet Explorer team here. The Internet Explorer team has been investigating this issue and has constructed a reliable repro which mimics the obscure set of factors needed to cause this problem in IE8.

It is worth mentioning that anyone who is experiencing a problem here in IE6/IE7 or Firefox is encountering a different problem that is not related to the IE8 issue described below.

-=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 the pre-parser is forced to restart (as 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=-
We believe this issue can be mitigated by avoiding constructs that cause a restart of the parser. The most common cause of restarts is specification of the CHARSET in a META tag. (There are other, more obscure causes of restarts, but the CHARSET is believed to be the most common).

By declaring the CHARSET of the page using the HTTP Content-Type header rather than specifying it within the page, you can remove one cause of parser restarts.

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.

-=Future=-
The IE team will continue our investigation into this issue and may elect to make available an update for IE8 to correct this problem.

thanks!
Posted by commanders1 on 6/9/2009 at 1:21 PM
Having the same problem, I found this post: http://kyle.baley.org/CategoryView,category,dasBlog.aspx

After excluding "ebResource.axd" from my blowery.web section, it worked again!

Kyle reports:
Turns out you don't exclude WebResource.axd from compression in blowery.web. Rather you need to exclude ebResource.axd. That's not a typo. Here is what my blowery.web section looks like:

<blowery.web>
<httpCompress preferredAlgorithm="gzip" compressionLevel="high">
<excludedPaths>
        <add path="WebResource.axd"/>
            <add path="ebResource.axd"/>
        </excludedPaths>
        <excludedMimeTypes>
            <add type="image/jpeg"/>
            <add type="image/gif"/>
        </excludedMimeTypes>
    </httpCompress>
</blowery.web>

For whatever reason, blowery has code that skips the first letter in its excluded paths. And I can't take any credit for discovering this.
(Source: http%3a%2f%2fwww.ventrian.com%2fResources%2fArticles%2ftabid%2f213%2farticleType%2fArticleView%2farticleId%2f46%2fEnabling-HTTP-Compression-for-DotNetNuke.aspx)