Simple question this time, is there a way in ASP.NET to set a decimal value HTTP Status Code instead of the common int status code?
Example, I would like to set a "403.4 SSL required" instead of just a 403...
Thanks :)
** EDIT
The comments below pointed me in the right direction, I just needed to set the Response.SubStatusCode.
By the standard HTTP only defines 3 digit numeric result codes. What you are seeing is IIS specific, it is the sub-status code which can be set and read from the HttpResponse.SubStatusCode property.
From MSDN:
The SubStatusCode property is only supported with the integrated
pipeline mode in IIS 7.0 and at least the .NET Framework version 3.0.
When you set the SubStatusCode property, the status is logged on IIS
7.0 if failed-request tracing is configured. Independent of whether tracing is configured, the code is never sent as part of the final
response to the request. For more information, see Troubleshooting
Failed Requests Using Failed Request Tracing in IIS 7.0.
There is no such thing as a decimal HTTP Status Code.
Whatever you're trying to accomplish isn't by using HTTP status codes.
No. RFC 2616 section 6.1.1 says it must be a "3-digit integer result code."
Related
I've discovered something peculiar that's been going on for the past 2 days.
I'm returning back custom JSON message in my Web API 2.0. E.g. when there's been an Unauthorized Response (HttpStatusCode 401)..it's only returning back the HttpStatusCode and NOT the JSON.
Simply put, anything apart from a HTTP Status Code 200 is NOT returning back the custom JSON that I've explicitly put in my ActionHandlers to return back.
This has happened recently, in the past 2 days. I've tested my code locally and I'm getting the expected output I need..the custom JSON error messages but as soon as I publish to one of my slots whether it be production or dev..only HttpStatus Codes are being returned.
Can anyone verify this for me? I need a way to sort this issue out or atleast have Azure take a look at this and tell me what to do. I suspect it's been an Azure update which I'm unaware of.
Probably some kind of customErrors logic kicks in when you are remotely testing your site. Those logics are usually disabled when browsing locally.
Check your configuration. Under IIS, there is also the httpErrors configuration which may interfere.
And have you set TrySkipIisCustomErrors to true when your code yields an error responses?
Ok, so I've figured out the issue.
Upgraded Visual Studio to 2015 to get the .NET Framework to use 4.6.
Changed all of my projects in the solution to point to 4.6, re-compiled, published and finally tested.
Errors are returning back JSON now too.
IMO, Azure could've atleast sent us an update. Anyways, posting this answer so hopefully anyone else using Web Api can easily forgo this issue.
I'm getting the error "HTTP Error 414. The request URL is too long." From the following article, I understand that this is due to a very long query string:
http://www.mytecbits.com/microsoft/iis/query-string-too-long
In web.config, I have maxQueryStringLength="2097151". Is this the maximum value?
In order to solve this problem, should I set maxUrl in web.config? If so, what's the maximum value supported?
What should I do to fix this error?
This error is actually thrown from http.sys, not from IIS. The error gets thrown before the request is passed along to IIS in the request-handling pipeline.
To verify this, you can check the Server header value in the HTTP response headers, as per https://stackoverflow.com/a/32022511/12484.
To get https.sys to accept longer request URLs without throwing the HTTP 414 error, in the Windows Registry on the server PC, at Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, create a DWORD-type value with name MaxFieldLength and value sufficiently large, e.g. 65535.
Reference: Http.sys registry settings for Windows
If you decide to make this change, then obviously it’ll need to be made in all environments (including all production server(s)) -- not just on your local dev PC.
Also, whatever script and/or documentation your team uses to set up new server instances will need to be updated to include this registry setting, so that your team doesn’t forget to apply this setting 18 months from now when setting up a new production server.
Finally, be aware making this change could have adverse security consequences for all applications running on your server, as a large HTTP request submitted by an attacker won’t be rejected early in the pipeline as it would normally.
As an alternative to making this change to bypass the http.sys security, consider changing the request to accept HTTP POST instead of HTTP GET, and put the parameters into the POST request body instead of into a long URL. For more discussion on this, see question Design RESTful GET API with a long list of query parameters.
As described in this answer -> What is the maximum length of a URL in different browsers?
The allowed length of a url depends on a combination of browser and server. Hence it's hard to say exactly how long the url can be. The answer recommends to stay below 2000 char in the url. I do not know why your querystring is so long. Can you shorten it? It's hard to give you any recommendations without knowing more about the solution and your query string.
Generally, Url has its own limits in length and if you set this value you may solve the problem for a while, but bear in mind that for a long url situations, best practice is working with forms. To be specific, it is better to use POST actions instead of Get.
just to complement, if you try with massive parameters, using Request ajax and receive de 414 ERROR. change the dataType property to JSON then submit as POST type.
this resolved my problem.
I was using Response.Header.Add() before I notice that my code might run on server set in classic mode. In such a case, the exception "This operation requires IIS integrated pipeline mode." is raised.
I switched to Response.AddHeader() to solve my issue. This function seems older, but it isn't deprecated. I would like to know, do you see any reason for using Response.Header.Add() over Response.AddHeader()? Could you please explain ?
Response.AddHeader() is an older method, geared towards IIS6. Response.AddHeader provides you with a basic way to add custom headers to the Response Headers collection, but doesn't really provide you with a means to otherwise manipulate the collection (like, you can't remove a header from the collection - though you can clear them all with Response.ClearHeaders()). Response.Header.Add() is newer and requires Integrated Pipeline Mode to function, which is only supported in IIS7 and later...
"The Headers property is only supported with the IIS 7.0 integrated pipeline mode and at least the .NET Framework 3.0. When you try to access the Headers property and either of these two conditions is not met, a PlatformNotSupportedException is thrown." -Linky
It's my understanding that IIS6 uses ASAPI to invoke .Net, effectively limiting how things like response headers can be worked with. With IIS7 Integrated mode, a "unified request-processing pipeline that combines the ASP.NET request pipeline with the IIS core request pipeline", providing greater flexibility in working within the request/response life cycle...
Here are a couple of links that may help illuminate the subject for you - Moving an ASP.Net Application from IIS 6.0 to IIS 7.0 and HTTP Request Lifecycle Events in IIS Pipeline that every ASP.NET Developer Should Know.
I hope that this helps!
I'm trying to get a SAML token from an ADFS instance. I followed the example found here (http://blogs.msdn.com/b/willpe/archive/2010/10/25/windows-authentication-adfs-and-the-access-control-service.aspx) to configure everything. The ADFS instance is configured by a different party, but setup as found in the article.
At first sight, it all seems to be working ok. But when I go into code and run a sample which should get me a token, I receive a (411) Length Required) response from the server. It doesn't matter much if I switch endpoints, errors stays the same. Seems like the response isn't even getting to the endpoint at all.
The Length Required error seems to have something to do with a missing Content-Length: 0 header line. I checked with Fiddler; it's not there. But the call is generated from within the .NET framework, so there really isn't that much I can do about that.
Any idea why the server might throw this error? Should I try to change the request, or disable the check on the server side? Or an option I haven't thought of perhaps?
Is there any way to add custom headers without creating HttpHandler? I've tried the following two APIs but the former is throwing error and the latter is working fine but when the page is either redirected or posted to another page. The header is lost. Thanks for your suggestion.
Response.Headers.Add()
Response.AppendHeader()
Environment: ASP.NET 3.5 & IIS 6
According to MSDN documentation:
"The Headers property is only supported with the IIS 7.0 integrated
pipeline mode and at least the .NET Framework 3.0. When you try to
access the Headers property and either of these two conditions is not
met, a PlatformNotSupportedException is thrown."
Since you are using IIS6 I'd expect you to get a PlatformNotSupportedException exception raised. Are you?
Try using Response.AppendHeader() method instead. For example:
Response.AppendHeader("CustomAspNetHeader", "Value1");
You can also use Response.ClearHeaders() to remove any headers first, if need be.