An asmx service we're hosting under IIS decided to attach below message at the top of xml response body rendering the xml invalid. The guid is unique in each response.
Your request could not be processed. Please press the back button on
your browser and try again. If the problem persists, please contact
technical support. Information below is for technical support:
Support Code: 7d6cbea0-9491-4cb0-9ca0-32f0a8b41bc4
I've limited access to the source; it does not appear like this is coming from the application code itself. Googling brings several hits current or cached having exactly the same behavior (variation of "could not processed" or "could not be processed" in different cases):
https://www.histiocure.org/jTlSn/about.aspx
https://webcache.googleusercontent.com/search?q=cache:8gRsTgrCarQJ:https://retirement.insperity.com/education.aspx+&cd=4&hl=en&ct=clnk&gl=us
https://www.perfectprovisions.org/index.aspx
Yet, I don't get any hit from technical sites like stackoverflow or MSDN. This is very puzzling; has anyone seen this behavior? Is it IIS doing this? What causes this?
BTW, the issue itself was resolved when AppPool was restarting but I'm worried that this can happen again anytime unless we get to the bottom of this.
Related
I have a static website on an Azure web server/portal that holds our company's documentation. Recently, I've been making changes to our code that sets our cookies to ensure that they comply with the browser SameSite requirement as explained here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
I've been able to fix all my scripts that create my cookies, but while testing them today, I see that there's this cookie message that still appears in my FireFox console:
Cookie “ARRAffinity” will be soon rejected because it has the
“sameSite” attribute set to “none” or an invalid value, without the
“secure” attribute. To know more about the “sameSite“ attribute, read
https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
This message only appears when I clear the cache from the site and load the page. Once I reload the page a second time or load any other page after that, I no longer see the message.
I believe this ARRAffinity cookie technically comes from Azure's Application Insights (AI)--or something on the Azure web server. It doesn't appear in our javascript files at all. We use AI for our analytics. Here is the code snippet that we got from Azure about two years ago. It gets injected into the header of each .htm page on our site:
var appInsights=window.appInsights||function(a){
function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c={config:a},d=document,e=window;setTimeout(function(){var b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTagName("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthenticatedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPage"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c["_"+f](a,b,d,e,h),i}}return c
}({
instrumentationKey:"<The Key>"
});
window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView();
(Note that <The Key> in the snippet above is actually a unique multi-character string that Azure gave us when we set up and configured the AI resource. I removed it here for privacy.)
I've since revisited the site where I got that code, but the snippet has changed to something newer:
https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript#snippet-based-setup
I'm not sure if I need to do anything to fix this.
Does ARRAffinity cookie come from some server-side script that Microsoft creates?
Do I need to do anything on my side to resolve this console message? If so, what?
ARRAffinity cookie is automatically created by Azure. You can turn it off by going to Configuration --> General Settings and then click on Off in the App Service as shown below.
As your's is a static website, i don't think this would be an issue. In fact, it is recommenced to turn ARR Affinity to Off for any Cloud Native applications.
When ARR Affinity is turned off, all the App Service instances (in a load balanced env) will be used effectively.
If ARR Affinity is turned on, all the requests for a given session will be sent to the same server irrespective of the load on it.
By default, the setting is on to to support legacy applications that needs Session stickiness.
Here's the situation: -
I have
<customErrors mode="On" defaultRedirect="error.html" />
in my web.config.
I also have custom error handling code in Application_Error (in global.asax.cs) that checks for certain well known exception types and redirects to custom error pages for each. If the exception is not a well known type then I simple return from Application_Error without calling Server.ClearError() so the default custom handling should take care of showing the page error.html.
But whenever my app throws up an unhandled (and not well known) exception I end up at the default Asp.Net error page - you know the one I mean, the yellow screen of death...
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.
Details: To enable the details of this specific error message to be viewable on the local server machine, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "RemoteOnly". To enable the details to be viewable on remote machines, please set "mode" to "Off".
I have checked the obvious stuff (like double checking that I am not throwing another error in Application_Error and I am not accidently' calling ClearError. It is definitely something fishy with this one web app (I made a little test web app and the custom error handling worked as expected) - that should rule out oddities in my machine.config file.
I am going to keep on scratching my head and trying things but in the meantime I thought I would put the question out here to see if anyone had any bright ideas.
PS. I am working on Windows 7 Business (IIS 7.5) but the same behavior is observed on Win server 2003 (IIS6).
Thanks Joe and Click for having a look but this problem is all my fault!
One crucial bit of information that I omitted from the description is that my web page flushes the response before the request is finished (see * below if you want to know why I do this nastiness).
It seems that once some content has been sent to the client, the customError handling no longer works. I can't say that this is a failing of the custom error handling because it would probably take some dark voodoo to tell a browser to redirect to once it had started rendering content!
Having said that I was hopeful that adding redirectMode="ResponseRewrite" to the customError node would help (maybe get the error page below the content I have already sent to the browser?) but that fails too. Nevermind.
A quick google yields this http://forums.iis.net/p/993221/1313916.aspx - and a chap on there has a work around that I will try. The technique suggested in http://forums.iis.net/p/993221/1399583.aspx#1399583 works. It is far from ideal (we have to read the web config) but it works.
(*) why am I flushing the response before the request is finished? Some of our pages return large reports which can take several seconds to generate. We send a "PLease wait + spinny gif" message to the clients at the start of these requests and flush that so that the browser renders the message + icon whilst it waits for the rest of the response. I think I shall investigate a less "hacky" way of achieving this.
In Flex 3 application I use HTTPService class to make requests to the server:
var http:HTTPService = new HTTPService();
http.method = 'POST';
http.url = hostUrl;
http.resultFormat = 'e4x';
http.addEventListener(ResultEvent.RESULT, ...);
http.addEventListener(FaultEvent.FAULT, ...);
http.send(params);
The application has Comet-architecture. So it makes long running requests. While waiting a response for this request, other requests can be made concurrently.
The application works in most cases. But sometimes some clients get HTTP request error executing long running request:
faultCode:Server.Error.Request
faultString:'HTTP request error'
faultDetail:'Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]. URL: http://example.com/ws'
I think it depends on user's browser.
Any ideas?
I experienced the same problem when I sent longer (3-4K!) parameter in HttpRequest. As soon as I sent smaller ones it worked (without refresh, reload or anything). I do not know if there is a limit on client side or on web server side of the length of parameters you can send but definitely this causes the issue.
url limitations may cause it
This error appears very generic and I would suggest trying to collect more information and sharing it regarding the issue.
This post appears similar to your situation.
This post might help you find more debugging information which would be helpful.
Which clients are affected?
Can you capture the http status code or the traffic being sent using Charles, Wireshark, or similar?
Try listening for the HTTP-status of the request, using flash.events.HTTPStatusEvent.HTTP_STATUS
That might give you some more info about what's going wrong.
I was going to open another question on essentially the same topic, but I figure two unanswered questions is worse than 1.
I get a similar intermittent issue from some users of a Flex application we have, but with some slightly different symptoms. The full range of information I can provide is:
It occurs on short (10ms) requests as well.
It appears to occur randomly.
The connection is over SSL.
It only occurs for users of IE, not for users using FireFox.
Once it occurs, users inform me they need to shut down IE and restart it (some users say they need to reboot, but I think that's less likely than just an IE restart). It appears to require a few minutes to reset itself.
It does not appear to affect the rest of the user's internet connection -they can continue to use other IE windows.
Once it occurs, it appears that no HTTPService request from the flex application will work.
It occurs (apparently) only for a small subset of users. Initially it
seemed to be due to their physical distance from the main server, but this no longer
appears to be necessarily the case (though it could be connection quality).
I'm not clear on what version of Adobe Flash the users are running.
Code was built with Adobe Flex 3.4 (linux)
The application does a wide range of requests, many in parallel though I've not been able to reproduce the problem.
Users do suggest this error occurs after they have come back to the application after a few minutes.
There appears to be no related server side request entry in the server logs, suggesting the request never reaches the server (possibly never leaving the client).
The server responds to all requests with the relevant cache headers to turn of IE caching.
The current workaround we have is to request users run the application in FireFox.
Full dump of the error is:
HTTP Status Code: null
Fault Code: Server.Error.Request
Fault Error ID: null
Fault Detail: Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]. URL: https://my.server/url
Fault String: HTTP request error
Fault Name: Error
Fault Message: faultCode:Server.Error.Request faultString:'HTTP request error' faultDetail:'Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]. URL: https://my.server/url'
Root Cause: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]
Many people have mentioned error 2032, a few even mentioning intermittent errors under IE only, but there are no mentions of the solution. If I ever find one, I'll update my post here.
Update
After talking to a user as this occurred, we found the following:
The user could open a new tab in IE, and load the same flex application up fine - so no internet connectivity problems.
The user could, in the tab with the flex app where the error occurs, load up google.com - so there appears to be no connectivity issue related to that specific tab.
The user could copy the address from the tab with the broken app into another tab, and the flex application would load.
The user could, after loading google.com in the tab where the flex app broke, copy in the flex app URL again, and immediately get the problem.
It appears that in my particular application, my flex app manages to break the flash plugin/VM to such an extent that after the break, no further requests to the URL are allowed.
I am so completely stumped by this I'm at the point of suggesting users use FireFox, or wrapping the application in an Air package.
I had somewhat the same problem here but with a Flash (Web - Flex 4.1 SDK) application.
after trying out a huge assortment of solutions we narrowed we finally came up with one that works pretty reliably for all systems, including newly installed machines.
A. add global event listeners at the root (or stage) of the application, on flex preinitialize stage.
IOErrorEvent.IO_ERROR
IOErrorEvent.NETWORK_ERROR
HTTPStatusEvent.HTTP_STATUS
ErrorEvent.ERROR
SecurityErrorEvent.SECURITY_ERROR
if an error is cought - event.preventDefault();
B. add event listeners on every loader used in the App for the following errors:
IOErrorEvent.IO_ERROR
SecurityErrorEvent.SECURITY_ERROR
HTTPStatusEvent.HTTP_STATUS
*to attempt recovery, like falling back to an external interface call...
C. place all the SWZ files from the bin-release folder together with the SWF file in the same path on the server you use to deliver your App.
in my case these are the files needed:
sparkskins_4.5.1.21328.swz
spark_4.5.1.21328.swz
textLayout_2.0.0.232.swz
rpc_4.5.1.21328.swz
osmf_1.0.0.16316.swz
framework_4.5.1.21328.swz
* to discover this i used Chrome developer console to see which errors occur on the page and discovered a chain of 404s when the app tries to download these files.
D. have a properly configured crossdomain.xml policy file which includes the allow http request xml tag.
<allow-http-request-headers-from domain="*" headers="*"/>
replace the * as needed in your particular case.
Cheers
Sounds like you might have more connections going out then the browser supports. Do you know exactly how many open connections exist at the time of the error?
Different browser allow different numbers of simultaneous open connections. IE 6,7,8 all allow different amounts: http://support.microsoft.com/kb/282402
Firefox: http://www.speedguide.net/faq_in_q.php?qid=231
I've had this exact issue happening in my Air app. I eventually realized that I had accidentally set the urlrequest.idleTimeout to 10. This timeout is actually in milliseconds and my webserver is local, so if I sent no parameters (no get or post) to my local server it would work. Whenever I sent any parameters along with the request of course it would fail because my script took longer than 10ms to run and return the data.
You may want to pay attention to slow loading scripts. You can debug by just forcing some static output and then stop that page from executing further. In my php page I put:
<?php
echo "hello=hi";
die();
?>
Also, make sure to debug it within the sandbox limitations. I am using a self-signed ssl cert and there are a lot of warnings when trying to connect to my local test webserver.
Hope that helps!
I'm finding this problem every now and then in my production website, and it has me absolutely stumped...
My app works perfectly in both dev and production, but every now and then, I get an e-mail from my global error handling with this:
MESSAGE: This is an invalid webresource request.
URL: /WebResource.axd
(which means that for some reason webresource.axd was requested without specifying any GET parameters)
I'm not doing anything with webresource.axd myself, I don't get any of my resources through it, it's only used automatically by .Net to serve it's typical JS for validators, etc.
Any idea why this might be getting requested without parameters?
Has anyone encountered this?
That definitely is a bot not doing very good job of crawling your web site. It processes your web form and locates reference to WebResource.axd, for example:
<script src="/site/WebResource.axd?d=MtIW_TBRtZCvAXDMJGwg4g2&t=633772897740666651" type="text/javascript"></script>
The bot expects static JavaScript files only and tries to download it by requesting WebResource.axd without parameters. The result is an exception thrown by System.Web.Handlers.AssemblyResourceLoader class and intercepted by Application_Error in Global.asax.
I believe this exception is harmless - the client will receive 404 error. You can safely ignore it.
We also have all of our errors emailed to us, and we occasionally get those too. They never seem to have a referrer, and the user agent is usually a little wacky. We write them off as bots.
I just checked a couple of the offending client IP's against Arin, and one them belonged to a web-spidering-type organization, so there's a little more evidence for the bot theory.
I would also log the useragent that made the request to WebResource.axd. It wouldn't surprise me if it was a bot crawling your site.
This discussion...
http://www.telerik.com/community/forums/aspnet/spell/this-is-an-invalid-webresource-request.aspx
... and this linked MSDN article...
http://msdn.microsoft.com/en-us/magazine/cc163708.aspx
... might shed a little light (though not much).
This problem has been solved thanks to your suggestions. See the bottom for details. Thanks very much for your help!
Our ASP.NET website is accessed from several specific and highly secure international locations. It has been operating fine, but we have added another client location which is exhibiting very strange behaviour.
In particular, when the user enters search criteria and clicks the search button the result list returns empty. It doesn't even show the '0 results returned' text, so it is as if the Repeater control did not bind at all. Similar behaviour appears in some, but not all, other parts of the site. The user is able to log in to the site fine and their profile information is displayed.
I have logged in to the site locally using exactly the same credentials as them and the site works well from here. We have gone through the steps carefully so I am confident it is not a user issue.
I bind the search results in the Page_Load of the search results page the first time it is loaded (the criteria is in the query string). i.e.
if (!IsPostBack) {
BindResults();
}
I can replicate exactly the same behaviour locally by commenting out the BindResults() method call.
Does anybody know how the value of IsPostBack is calculated? Is it possible that their highly-secure firewall setup would cause IsPostBack to always return true, even when it is a redirect from another page? That could be a red herring as the problem might be elsewhere. It does exactly replicate the result though.
I have no access to the site, so troubleshooting is restricted to giving them instructions and asking for them to tell me the result.
Thanks for your time!
Appended info: Client is behind a Microsoft ISA 2006 firewall running default rules. The site has been added to the Internet Explorer trusted sites list and tried in FireFox and Google Chrome, all with the same result.
SOLUTION: The winner for me was the suggestion to use Fiddler. What an excellent tool that no web developer should be without. Using this I was able to strip various headers from the request until I reproduced the problem. There were actually two factors that caused this bug, as is so often the case with such confusing issues.
Factor one – Where possible the web application uses GZIP compression as supported by all major browsers. The firewall was stripping off the header that specifies GZIP decompression support (Accept-Encoding: gzip, deflate).
Factor two – A bug in my code meant that some processing was bypassed when the content was being sent uncompressed. This problem was not noticed before because the application is used by a limited audience, all of which supported GZIP decompression.
If they're at all tech-savvy, I would have them download Fiddler or something similar, capture the entire HTTP session, and then send you the saved session. Maybe something in there will stick out.
Meanwhile, see if you can get an install of ISA Server (an evaluation install, if you have to, or one from MSDN if you have or know anyone with a sub) and see if you can replicate it locally.
Is it possible the client has disabled Javascript and it's not picking up the _EVENTTARGET form value?
It might be some sort of proxy which creates a GET request out of a given POST request...
I am not sure how the IsPostBack is calculated, but my guess would be that it checks the HTTP request to see if it's a POST or a GET...
Ohh, yeah. It's definitely NOT "_EVENTTARGET" BTW...
I know this since Ra-Ajax does NOT pass any of those parameters to the server and they (Ra-ajax requests) are processed as IsPostBack requests...
Location, location, location. Check the user's culture. Normally that causes issues.
Could you create a test Post Page that passes the same things that your search page does, and in the Page_Load write back all of the post to make sure they are getting passed, particularly the __VIEWSTATE.
foreach (string key in Request.Form)
{
Response.Write("<br>" + key + "=" + Request.Form[key]);
}
Then ask one of the users to forward back what they see on that test page.
EDIT: There is documentation that some firewalls can corrupt the VIEWSTATE and some methods to get around it: View State Overview
Check the IIS logs to see if the request even makes it to your server. The ISA setup might be caching the initial request and serving that up in the succeeding requests.