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.
Related
I have a very basic Single Sign On app built on VS 2015 using MVC and Web Forms. It is supposed to be a simple proof of concept and is based on some code found here and here which are essentially the same things. I've finally gotten it all converted to use .Net 4.5 but when running it on my local server it throws a 404 with no debug information.
The 404 itself wasn't initially a surprise as I was supposed to be able to change the url to one of the secure pages (for instance /WebSecApp1) which would redirect me back to the signon page but no matter what I put as the url I get the 404.
I've also tried changing the urls in the code so that they contain the port numbers for the localhost but that doesn't work either.
It was suggested to me that the RouteConfig.cs could be the culprit but I don't see how that could be since I'm calling a single page with no parameters.
I know this is kind of lite on details but does anyone have any suggestions?
Yes this looks like a routing issue as you also thought it to be. Routing is essential for web api too .Pls see https://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection. Does your api request look like this
GET http://localhost:34701/api/products/1?version=1.5&details=1
You do have to mention the port in the request.
While the routing that Arathy mentioned above was partially to blame, the real problem turned out to be relatively simple. In my case simply selecting Properties->Web for each of offending pages and setting "Override application root URL" to checked fixed the whole 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!
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."
I'm using CouchDB as a data source for a C# web service.
Being RESTful, CouchDB passes back a status code of 404 when asked for a document that does not exist. The standard .NET web request wants to throw an exception at this but (to me, at least) communicating that a data source has returned "no results" via an exception is utterly horrible; and it's a stink I really don't want wafting around in my code...
Is there any replacement for WebRequest I can use that will allow me to deal with status codes as I see fit?
EDIT: Just to clarify, due to the responses I've had so far: I do not want to hide the exception that WebRequest throws. I am looking for an alternative to the standard WebRequest that does not throw exceptions based on status codes as .NET's interpretation of what constitutes an error doesn't seem in-line with REST principles.
EDIT #2 I really need a 3.5 compatible way of doing this; sorry for not being specific about that at the start.
The HttpClient library does not throw exceptions after the request. See this for usage examples.
I have not used them but there are several dedicated C# CouchDB client libraries.
There is CouchOne's list of CouchDB drivers.
Also there is the CouchDB wiki list of C# clients.
My personal preference is to stick as closely to the HTTP layer as possible. HTTTP is very simple and the CouchDB API is very simple. There is no need for middleware to access it. (It is unfortunate that your WebRequest class apparently has this bug.)
I'm not sure what's your problem. If you don't want to get 404 when asking doesn't exist documents, I think you just need to add a wildcard application maps in your IIS settings and uncheck the "Verify that file exists" box.
I have a custom site I'm building with automatic url rewriting using a custom engine. The rewriting works fine as long as the page url doesn't end in somehting like .htm or .html. For these pages it goes directly to the iis 404 page instead of hitting my rewriting engine first.
I have the * wildcard handler in the "Home Directory" section of the IIS6 configuration of that website but these urls seem to be ignored by it (altho things like css, jpg, js, etc to get sent to the url handler in my web project). How do i set up IIS6 to force these urls to get sent to the handler, while still serving the page if it exists normally?
The handler basically does this
if (!File.Exists(Request.Path))
{
doMyRewriting();
}
I have to assume that using a block like this (just and example, the real one does some other stuff to format the Request.Path to be proper with everything) should run the "doMyRewriting()" if the requested file does not exist otherwise it will serve the page normally. Am I mistaken?
If I tell IIS specifically to send .htm and .html pages thru to the .NET handler the rewriting works but if the page is actually there it will not serve it.
Any help would be greatly appreciated.
Thanks in advance!
Don't know if you can or would want to do this, but there is the Ionics Isapi url rewriter you can use.
http://www.codeplex.com/IIRF
Basically install that then set a rule to remove the .html that way it hits your rewrite engine. I use it on IIS 6 with several of my blogs.
I think if you are having IIS send all requests to .NET and your handler, then your handler will need to detect if the page exists and serve it instead of rewriting.
UrlRewriting.NET has an option to do this - you might want to look at their code to see how they're handling this case.
In my opinion, rewriting URLs with IIS 6 is best handled with an ISAPI filter written as unmanaged native code. Otherwise, you run into the issues you've mentioned - having to map all extensions to ASP.Net and losing the ability for simple file handling. With an ISAPI filter, you can choose to not rewrite some URLs and let IIS handle them as normal.
To get started, I suggest reading the ISAPI Filter Overview on MSDN.
If your filter absolutely needs the .Net framework runtime, it is possible to write a small ISAPI filter shell that hosts the CLR and forwards the requests to some managed code. The Filter.Net Framework takes this approach and may be suitable for your needs. There is the small drawback to this approach in that you will have to use the same .Net version as any ASP.Net applications that are run in the main IIS process.