Hi everybody I'm writing an handler to manage .html files. What I want is to intercept every call made towards html or htm files and check if it exist the counterpart in aspx. I reached perfectly my goal, but I would like also to manage the call when the aspx file doesn't exist. The problem starts when, given an html files that hasn't a correspondance in aspx, I would like to process the html file as it is, so as static page. Leaving unmanaged this part of work, results in a blank page output, but if I try to forward the page with a Server.Execute or Server.Transfer or Response.Redirect, in any case IIS intercept the new call and forward it to my handler again. Well, this sound normal, since I had written a .html handler, but how to manage this. In a first attempt I though to forward my request to the static handler with some c# code. Nothing that had worked. I then moved through IIS configuration, setting up the staticfileHandler after mine, believing that it's all what I need. In this way I got again a blank file. Is there a way to manage this kind of situation? Thanks in advance. Andrea

You need to map the .HTML extension to the ASP.NET ISAPI filter in IIS

Why to the ASP.Net ISAPI Filter ... I would like to process normal static html file. Not aspx pages. I'm able, inside the handler, to correctly redirect to aspx in case I need. What I'm not able to do is let html page be processed as it is. Andrea

Hi,

You might want to have a look at this thread:

http://forums.asp.net/t/1188310.aspx

 Zhao

thanks for you reply but this doesn't overcome to my question. Why I should use the IIS ISAPI filter suggested in the previous reply, and worse than all it seems to not be able to solve my problem.

Taking the example inside the blog I got redirected, I should add  a type declaration like this

<httpHandlers>
<add verb="*" path="*.html"  type="Myclasshandler, MyAssemblyName"/>
</httpHandlers>

that is what I've setup.

Should I add a second entry just below the first one that redirect *.html files to the ASP.Net Isapi filter?

Is this what you mean? Or should I add a second type declaration that point to the asp.net isapi (if this is allowed - I don't know)

Thanks
Andrea

 Well,

definitely I think this is one thing that could be improved in the framework.

 I've opened a suggestion feedback; in case someone could find this useful here is the link.

 Bye

Andrea
 

 

 

Hi Andrea,

Thanks for your feedback. Our development team will aware of this.

Actually, the wildcard mapping is based on ISAPI Extension. Just some further information, IIS 7 introduced integrated pipeline which enables managed application modules to apply to all request types, you can see this:

http://mvolo.com/blogs/serverside/archive/2006/10/22/Extending-your-IIS-7-server-with-.NET.aspx

Another method you can consider is using Url Rewritting; .html in the Url can be rewrite to .aspx and thus to be handled by ASP.NET.

Hope it helps.

 Zhao

I cannot use url rewrite. The main problem on what I focus is make a transition component that let me switch a web site a bit per day. So imagine a 50k pages web site. It's not possible to make a turn over in just one day nor a week. It could require a long time, and the new dynamic web page should be available immediately.

So what's the solution?

I thought to an httphandler that given a path, extract the filename, check if it exist a counterpart with extension in aspx, if yes it redirect the new version instead the html one.

Problems come out, in integrated pipeline mode that IIS7 offer. Don't mislead me, it's really wonderful, but for what I've noticed once an handler catch a request it cannot move it out on another handler. This what mean. In my case having done a .html mapping, all the request that cannot be satisfied by my handler result in a blank page (null will be write in the context).

This problem shouldn't exist in IIS6 where effectively the web site is running, since just mapping .html web page to aspnet_isapi.dll let Asp.net catch the request and process internally, passing through my handler and - I think but I didn't test it - whenever the handler doesn't make anytning move the request to the next one (Maybe staticfile). As I said I didn't test this.

But what when theorically the web site will be moved on a W2K8 web server with IIS 7? Should I go through compromise using old classicmode app pool just for this? Why cannot use the new Integrated mode?

So the best solution I found is, at the end of the handler, when no one of the previous condition has been satisfied, open a strem with the existing .html file and response it back into the context. This definitely solve the problem both in IIS 7 and IIS 6 (tested it).

This could be a solution until a sort of request redirection method through handler will be implemented.

Andrea  
 

You CAN use URLRewrite.

Forget about handlers - go with a MODULE. Catch this in BeginRequest, check, decide what path to render and rewrite the request. This way the selected HANDLER will be the one matching your INTERNAL file type, not the one matching the URL.

Example:

* Request comes for /a/a.html

* Module checks for existence, sees nothing, sees /a/a.aspx, uses Rewrite on the resquest.

* ASP.NET further processes the request. which is now for /a/a.aspx and selects the right handler.

 @NetTecture

 Certainly a module is a lot easier to mange and doesn't create trouble like the one I described. But have you read the official documentation about module? Since they answer to every file request, I think that in a long term scenario it would be absolutely unnecessary implement a module because in a later usage I don't need at all.

Certainly I can remove the handler at later stage, but this would mean recompile and redistribute the app too, so spend no-payed time on a dismissed activity.

Apart from monetary focus point, what I want to focus here is that it would be better a new implementation like that one I described rather than finding workaround like using module instead of handler.

If at Microsoft someone though to handler as something useful would mean that the dev team in total found it a good way to offer programming support. In this prospective I think that giving more power to programmers would be better, and in this case some MS guy could have a look into what I'm proposing and feel free to report it as an implementable as well as time-wasting facility.

That's all. I got my solution working ... but opening a stream it's a real workaround that could he avoided with an handler request redirection support.

 Andrea
 

 

Certainly a module is a lot easier to mange and doesn't create trouble like the one I described. But have you read the official documentation about module? Since they answer to every file request, I think that in a long term scenario it would be absolutely unnecessary implement a module because in a later usage I don't need at all.

Sorry? Let us not go into the fact that you may actually want to use the handler long term, in order to get rid of standard file extensions like every good website should (why TELL The user you use .aspx? Why have a ".html" at the end? The MIME type has all the info for the browser, and if you change technologies, you are more stable with non-suffix-URL's), there is absolutly NOTHING that stops you from removing the handler again.

Apart from monetary focus point, what I want to focus here is that it would be better a new implementation like that one I described rather than finding workaround like using module instead of handler.

Absolutly not a workaround. The handler is supposed to be at the end of the request chain, and not meant to be replaced. In fact, the moment it is created by the HandlerFactory, a lot of things possibly happen, denepding on the interfaces the handler implements (IHttpHandler is not all there is). Replacing the handler at this stage would not allow ASP.NET to "undo" parts of what happened to the request due to the marker interfaces.

Example? Session state support is marked by an interface, and implementing it has grave consequences for performance (all requests with the same session state are serialized, instead of handling them parallael).

A handler deciding at exeution time that it needs to replace it self with another handler would mean ASP.NET would have to implement all features on every request. Now, THIS is pretty stupid - for example, serving static files definitly does not require access to session state. The performance implications are tremendous - not only does it concur processing orverhead, it also means hat image requests are lined up, instead of serving 4 at a time. This really makes a hugh difference.

The MS approach is absolutly logical - do everything in modules, except the actual page processing which is done using the handler.

I am writing a CMS like system too, at the moment - coming from one we have for IIS 6. It looks now that contrary to you I will not fight the system, but use a handler to decide where to handle a request, rewriting the request on the way down. Then handlers can be put into the game as Microsoft wants, without fighting the system.

@NetTecture

The handler aren't supposed to be at the end of the chain. Both IIS6 and IIS7 catch the file extension in the middle of the pipeline and routw the request through them and eventually skip the rest of the pipeline process according to what you handler is able to manage (read programmed).

This mean that in both case, HttpModule and HttpHandler, the HttpApplication is created, but at a certain point in the process you are able to skip a lot of processing and avoid memory wasting. For example, why use a SessionStateObject that HttpModule certainly provide to you if you know that it's not required?

In my case, since I knew that .html doesn't require SessionState, Authentication and bla bla bla ... why use a Module and an if inside the code to check file extension and eventually route the process away without doing anything while I can directly manage the .html file by myself without any other .net processing?
According to your answer you find better to do dozen of if check instead skip them at all. Sorry, I think that all the round trips avoidable to the server should be avoided.

About my previous monetary consideration ... in both cases is also true that simple acting on the web.config is enough to exclude both httpmodule and httphandler from the execution pipeline, so this wouldn't be a real mess.