I've set up a custom error page to handle errors thrown through my site.
I'm running asp.net 3.5 with IIS 7.0 on Godaddy shared hosting ("deluxe" account).
Normally, if I set Response.StatusCode = 412 the server outputs:
Server Error
412 - Precondition set by the client failed when evaluated on the Web server.
The request was not completed due to preconditions that are set in the request header.
Preconditions prevent the requested method from being applied to a resource other than the one intended. An example of a precondition is testing for expired content in the page cache of the client.
I already figured out how to prevent the server from automatically outputting the above message and instead execute my custom error page. What I'm stuck on now is figuring out how to access the long description of the error message.
Response.StatusDescription is "Precondition Failed" - which is expected...but is not really what I want.
Is there anyway to get the long description the server normally sends?
*Note that in order to prevent the default error message I had to set Response.TrySkipIisCustomErrors = true immediately after setting the Response.StatusCode to 412.
The long description is hard coded into 412.htm in this case. Since you have set up your own custom error page, this default supplied page is no longer used. This verbose message is not a part of the ASP.NET Response object.
Related
I have a couple Azure VMs behind a Basic Load Balancer with an HTTP URL Health Probe for the Backend Pool. To mark a server down, that URL returns Status Code 503 (Service Unavailable), but when I call that page from those VMs, the Status Code returned is 403. That still has the desired effect, I suppose, of marking the server down - but I dont understand why the code I set has changed.
This is from an ASP.NET web forms application on the VMs. I look at developer tools in the browser, and from my local machine or from a Dev server on our local network, that page returns Status Code 503, but calling that page from the VMs in Azure, the Status Code is 403.
Here's where I set the Status Code in that page:
Response.Clear()
Response.StatusCode = 503
Response.Flush()
I suppose I should mention that my local is a Windows 10 box, and the server VM is Windows Server 2016. Both are running IIS 10. The application is compiled with .NET Framework 4.6.
Here's the dev tools from my localhost:
Here's the dev tools from the server in azure:
Why the change? Anything I can do to stop this behavior?
So today I tried enabling Failed Request Tracing, but either something wasnt set up correctly, or the error was being handled elsewhere, and didnt result in any failed requests being logged.
Since I wasnt getting any failed requests logged, I opened up Process Monitor and could see that immediately after the call to my Health Probe page, I was getting a call to my custom HTTP Error page. That page must have been what was giving the 403 (dont know why, b/c that page works correctly for other HTTP Errors with a friendly error message and logging of the error to my custom error tracking solution).
I was going to change the Status Code to see if there was something special with the 503 that I was setting that was handled differently in IIS, but that got me thinking about how I was setting the status code...
In my research today, I saw this page https://www.leansentry.com/HowTo/AspNet-Response-Flush-Poor-Performance which cautions against using Response.Flush(). The code that I had implemented was in the Page_PreRender method, so there's not really a need to Flush there anyway.
I removed the Response.Flush and of course, my troubles went away.
The Health Probe page no longer triggers an Error from the Azure VM, and therefore, the status code that I get in my client browser is the 503 that I set in code.
So I guess this case is closed. I will need to figure out why the HTTP Error page was throwing a 403 instead of returning the friendly error message, but that should be easy enough...
I am trying to solve an issue with the Report Viewer control displaying the message:
The request failed with HTTP status 401: Unauthorized.
rather than a report. This message is shown in the location where the report would be displayed. The Share Point parts of the page are displayed normally.
This occurs in a Report Viewer control on a SharePoint 2013 page.
Some other reports on other pages show up just fine. In Report Server, the browsing permissions on these reports are the same.
A testing environment with the same configuration is working correctly. I could not find any differences in the web.config on the web server and in the RSReportServer.config file on the report server.
I http traffic from my browser, using the Network tab in the IE developer tools and saw something remarkable. POST Requests from javascript to the report server control are like:
/Reserved.ReportViewerWebControl.axd?OpType=SessionKeepAlive&ControlID=597f9e1be96e4291b847ce06da66940d
and receive a HTTP 500 status, whereas the response body is just two bytes:
OK
The report that works correctly, issues similar requests, but just receives HTTP 200 status, also with OK as response body.
On my testing environment, thing are different, again. The report issues three requests to ReportViewerWebControl.axd. The first get a HTTP 401 status. The next request adds an Authentication header with an NTLM token. This also gets an 401 status. The third adds another NTLM value and gets a 200 status.
This looks like some challenge mechanism and I found an MSDN article Error: The request failed with HTTP status 401: Unauthorized when you open a report in Microsoft Dynamics CRM 4.0 and tested with added to my RSReportServer.config file. This did not help and this key is also absent in my testing environment.
I also enabled FailedRequest logging to get more insight in the Internal server error, return by the requests to ReportViewerWebControl.axd. This logging is very elaborate, but I could not find anything pointing to a cause of this error.
Under request summary it reads
188. view trace
Warning -MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName ManagedPipelineHandler
Notification EXECUTE_REQUEST_HANDLER
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 0
ErrorCode The operation completed successfully. (0x0)
ConfigExceptionInfo
and under Authentication & Authorization
No. Event
60. view trace -AUTH_START AuthTypeSupported MapCliCert
61. view trace -AUTH_END
64. view trace -AUTH_START AuthTypeSupported Basic
65. view trace -AUTH_END
68. view trace -AUTH_START AuthTypeSupported NT
70. view trace -AUTH_END
91. view trace -FILTER_AUTH_COMPLETE_START
92. view trace -FILTER_AUTH_COMPLETE_END
I do not understand what all of that means, but it is the
ErrorCode The operation completed successfully.
looks like a contradiction.
Does anyone have suggestions on next steps to tackle this problem?
I would like the following behavior in regards to error statuscode responses:
In JsonResult Actions (for AJAX postbacks), return custom body along with some error statuscode
For errors in other action methods, show IIS (custom) error page
For 404 errors, show IIS (custom) error page
In local environment: For errors in non-json action methods, and 404, show ASP.NET error page with stacktrace
If I set existingResponse=Replace in the httpErrors element in web.config, the IIS error pages override any response with an error-statuscode. That is I cannot return a custom json response.
If I set existingResponse=Auto I can return a custom json response by setting Response.TrySkipIisCustomErrors=true, but then the ASP.NET (custom) error pages are shown for any other error statuscode. That is, it never falls back to the IIS error pages. It seems that ASP.NET automatically sets the TrySkipIisCustomErrors on server errors, which I do not want.
Is there any way to achieve what I describe? I could possibly use the ASP.NET customErrors section instead, but I realize it also has disadvantages, as described here:
https://dusted.codes/demystifying-aspnet-mvc-5-error-pages-and-error-logging
One could use a combination of httpErrorsand customErrors, but the latter does no support ExecuteURL - only static error pages. That is unfortunate since I would like to make use of the master Layout.cshtml.
Any suggestions?
Whats difference between return new HttpStatusCodeResult(500) and cause a real error in the action (like division by zero)?
I'm asking because my customErrors works fine when a error like division by zero ocurred, but if i return new HttpStatusCodeResult(500) the customError dont show my page
HttpStatusCodeResult is for notifying the browser of the result of an action, using an actual HTTP status code. For example, if the browser tries to load an image that is no longer available, you could send a 404. If the user is attempting to access a resource that requires authentication, you could return a 401.
Errors caused by your code often don't need to inform the browser of an error, but instead need to inform the user, using an error page with a message. This error page though, would (most likely) be sent to the browser with an HTTP status code of 200.
tldr; these are two different types of errors with different meanings, meant for different recipients.
I've got a bit of an odd situation that recently came up in a security scan and I'm having trouble explaining it. In short, the following URL always returns HTTP 400 and a YSOD:
http://www.mypal4me.com/C:badfile
This site is ASP.NET 4 and is hosted on MaximumASP under IIS7.5. This site is configured with custom errors turned ON and a default redirect page. This is evidenced by causing request validation to throw you off to the error page: http://www.mypal4me.com/?%3Cscript%3E
The only way we've found to send this request off to the custom error page is to add an <error statusCode="400" path="/error.htm" responseMode="ExecuteURL" /> entry under system.webServer.httpErrors in the web.config (obviously this hasn't been done on the site above but has on other MaximumASP sites).
So my question is twofold:
Why is this request not being caught by the usual .NET error handling and the custom error page served as a result?
Why do I only see this happen at MaximumASP - I can't reproduce an HTTP 400 with that pattern in any other IIS/ASP.NET environment.
http://msdn.microsoft.com/en-us/library/s57a598e.aspx
ASP.NET 4 also enables you to configure the characters that are used
by the URL character check. When ASP.NET finds an invalid character in
the path portion of a URL, it rejects the request and issues an HTTP
400 (Bad request) status code. In previous versions of ASP.NET, the
URL character checks were limited to a fixed set of characters. In
ASP.NET 4, you can customize the set of valid characters using the new
requestPathInvalidChars attribute of the httpRuntime configuration
element, as shown in the following example:
It's likely request filtering, specially it doesn't like the C: bit, fearing that it is a directory travesal attack of some sort. Many webhosts security settings will block suck a url.
A most likely guess at the the product in use is UrlScan, http://learn.iis.net/page.aspx/473/using-urlscan
Because this filtering runs at a much lower level in the call chain, the request itself is never passed to your asp.net application process (As many of the attacks that are mitigated are designed to trick IIS into returning files outside your application folder). Thus any application defined error routines won't see it, however an IIS error page (which is what your configuring via webc.config) will be triggered.