When setting up asp.net error handlers for things like 404 errors, it is more 'efficient' to do this in IIS, or handle it in the Global.asax Application_Error event? I know the latter will be called, and I want to log this information in a database, but should I then just return without any redirect and let IIS do the redirect, or would it be better to do a response.redirect inside application_error once we've logged it?
Handing in IIS is more efficient but in glabal.asax allows you to log it or react to it.
Remember the decision is not commonly yours but based on the mime setup. So if a resource has been set to be hanled as a static content, you will not receive it in the ASP.NET.
Related
I use an Application_Error handler to log all unhandled exceptions; generally it works well, but 404 errors always are skipped. Any ideas what might be the reason?
Actually, that is because that's an http protocol error returned by your web server. It's not a .net framework exception and thus it can't be handled by asp.net. However, you can configure IIS to serve a custom page when it returns a 404 error and this can be done through your web.config file. Needless to say that this custom page could be an aspx page where you can add some custom processing such as logging the error ;)
404's are not always caused by exceptions. You can just set the Response.Status* fields to generate a 404 response.
Use Application_EndRequest to examine the response and act on it.
In the standard redirection scenario, the browser is sending another request to the server.
How to achieve internal IIS redirection with all web application lifecycle events (BeginRequest, AuthenticateRequest, ...) to be retriggered (not just calling the another handler)?
CLARIFICATION: I mean just redirection inside the same web app.
It depends where in the page lifecycle you are. Within a page you can use server.transfer, but it won't work with MVC & it's a bit hacky.
The context has some methods, such as rewritepath that let you change the path that is executing, but again, there are limitations.
iis.net has a useful article on this.
I have gone through the links mentioned below,
iis forum and HttpModules & Server.Transfer / Server.TransferRequest / RewritePath problems. but unable to catch the concept behind these transfer methods.
How are they works? And which one is preferred in different situation?
Can someone explain me TransferRequest vs Transfer methods for server side transfer in asp.net and its roles?
Thanks in advance
HttpServerUtility.Transfer Terminates execution of the current page and starts execution of provided URL.
This basically maps and executes a new ASP.NET Page (or serves a static file) corresponding to the url provided. It does this in-place in the current request pipeline, without applying new configuration to the new url, or re-running IIS modules for the new url. Because of this, its very fast, but it also prevents a lot of scenarios that are possible with TRQ.
HttpServerUtility.TransferRequest Performs an asynchronous execution of the provided URL.
This is a full IIS child request under the covers, which allows it to re-run the entire request pipeline for the new request as if it was a separate request, getting the correct configuration for it, and running all of the normal IIS modules including authentication, authorization, etc. For example, IIS will apply the authorization rules for the new url, as opposed to the previous url.
TransferRequest re-runs the entire request pipeline as if it were a separate request. This means that IIS and ASP.NET modules are re-applied; authentication and authorization rules for the new URL will be honored. Note that TransferRequest requires the integrated pipeline mode of IIS 7+, and the transfer can be to an ASP page or another resource like an XML file.
Transfer transfers execution from one ASP page to another ASP page on the server. Unlike TransferRequest, IIS and ASP.NET will NOT verify that the current user is authorized to view the resource delivered by the Transfer method. If you need to force reauthorization, and integrated pipeline mode is not an option, call Redirect instead of the Transfer method. Redirect triggers a client-side redirect so that the new request will be subjected to all authentication and authorization logic of IIS and ASP.NET.
I have created a custom http handler (IHttpHandler).
This handler can be called from any place in the application.
eg: domain.com/file.handlerExtension or it can be domain.com/folder/file.handlerExtension
I have security on my application, but this handler should be available to anonymous users also. Because of this approach it is a mess to create a location element in web config for every posible location from where the handler can be called.
Is there a way to remove check of Authentication and Authorization on a specific resource or Handler in IIS7?
As far as I know - No - this is handled as an HttpModule (if not using iis authentication) - the application configuration defines urls to protect. The only hope may be to hack it so it thinks the user is already authenticated (not even sure if it would work) prior to the Authentication httpModules running which would mean changing processing order. and even then you would have to have some logic built in to say 'force authentication for a request to THIS uri'
MVC's security handling is a bit better IMHO as you can simply use attributes on your controllers or methods to define security and in that case your app would simply remain anonymous for those request.
In our asp.net 2.0 application we have the an HttpModule and HttpHandler. They are registered in web.config to handle requests for certain file types.
The request is initiated asynchronously from client side using MS AJAX.
I noticed something strange:
HttpHandler:ProcessRequest is not entered on every HttpModule:EndRequest which seems like incorrect behavior since my understanding of the flow of events:
HttpModule:BeginRequest > HttpHandler:ProcessRequest > HttpModule:EndRequest. For some reason, the handler part is sometimes skipped.
What could be causing this?
If I understand correctly, HttpModule would get executed for every request which comes to your application, while the HttpHandler would execute only for the registered extension.
So, there could be other request to the app apart from the ones you make to your handler.
Do you have that file type set up in IIS to be processed by .net?
I believe that calls to Server.Transfer and Response.End can short-circuit the pipeline, is it possible a branch of your logic does this?