Using an HttpHandler to redirect a certain extension to ASPX pages behind the scenes

[Guest]

Please don't ask me why I'm doing this (trust me, it makes sense in my system), but I'd like to basically redirect requests for a certain extension (thus a handler) to an ASPX page behind the scenes.

I've created a handler and set it up to handle the extension in question. In my ProcessRequest, I'd like to basically figure out which ASPX page to "forward" the request to. I've tried all sorts of methods (Server.Transfer and Server.Execute for instance), but they all have their downfall.

One problem is the ASPX page in question always sets his form "action" to the name of his own page (ending in ASPX). I'd like the "action" to be the URL I'm currently at (which will in turn eventually get handled by the same ASPX page). I figured out a cheesy way to get the action to properly have the correct output by using the Server.Execute overload that allows you to redirect the output to a TextWriter and then modifying the output and sending that out. The problem with that approach is now the IsPostback of the actual page never thinks it's a post back and controls never get their events fired.

Does anyone know of a way to do what I'm trying to do?

 

[Kevin Spencer]

Why don't you just assign ASP.Net as the handler for this extension? Then
you don't need an HttpHandler to redirect. ASP.Net will handle the request,
and your ASP.Net pages would just have to have the same extension.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Please don't ask me why I'm doing this (trust me, it makes sense in my

system), but I'd like to basically redirect requests for a certain extension
(thus a handler) to an ASPX page behind the scenes.

I've created a handler and set it up to handle the extension in question.

In my ProcessRequest, I'd like to basically figure out which ASPX page to
"forward" the request to. I've tried all sorts of methods (Server.Transfer
and Server.Execute for instance), but they all have their downfall.

One problem is the ASPX page in question always sets his form "action" to

the name of his own page (ending in ASPX). I'd like the "action" to be the
URL I'm currently at (which will in turn eventually get handled by the same
ASPX page). I figured out a cheesy way to get the action to properly have
the correct output by using the Server.Execute overload that allows you to
redirect the output to a TextWriter and then modifying the output and
sending that out. The problem with that approach is now the IsPostback of
the actual page never thinks it's a post back and controls never get their
events fired.

 

[Guest]

Are you suggesting I rename an ASPX page to my new extension and associate that extension with the same DLL that ASPX is associated with in the IIS configuration (aspnet_isapi.dll)? If no handler is configured in the Web.config, how will it know what to do with requests of that extension? It won't know to treat them like an ASPX page (in fact, it will just output it as text). Is there something else I'm missing? Do you have a link that shows how to do what you're referring to

As far as a handler, basically this thing has "virtual" directories. It uses directories to organize things in a hierarchical manner. It then passes almost all requests to one ASPX page that knows what controls (ASCX's) it needs to load for that request (based upon where it is in the heirarchy)

I've implemented this system using an HttpModule with ASPX extensions currently (and it works like a champ), but I'd like to not call the HttpModule for everything in the IIS application directory and would like to limit this type of processing to one known extension. The HttpModule is currently doing a Server.Transfer to an ASPX page, and the request has to end with the same name as the ASPX page (there's no way that I can tell to override the action output of an ASPX page)

I hope all of this makes sense...

 

[Kevin Spencer]

Hi Kentamanos,

You would have to add an ISAPI mapping in IIS, as well as some web.config
settings.

But, from what you've now described, I don't think that would take care of
your problem. The way you've described it, I don't know of any way to have a
Request transferred to an ASP.Net Page without the problem you're describing
regarding PostBack. The System.Web.UI.Page class was designed to work in a
certain way. You might have to create your own "Page" class to accomplish
your goal.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Are you suggesting I rename an ASPX page to my new extension and associate

that extension with the same DLL that ASPX is associated with in the IIS
configuration (aspnet_isapi.dll)? If no handler is configured in the
Web.config, how will it know what to do with requests of that extension? It
won't know to treat them like an ASPX page (in fact, it will just output it
as text). Is there something else I'm missing? Do you have a link that shows
how to do what you're referring to?

As far as a handler, basically this thing has "virtual" directories. It

uses directories to organize things in a hierarchical manner. It then passes
almost all requests to one ASPX page that knows what controls (ASCX's) it
needs to load for that request (based upon where it is in the heirarchy).

I've implemented this system using an HttpModule with ASPX extensions

currently (and it works like a champ), but I'd like to not call the
HttpModule for everything in the IIS application directory and would like to
limit this type of processing to one known extension. The HttpModule is
currently doing a Server.Transfer to an ASPX page, and the request has to
end with the same name as the ASPX page (there's no way that I can tell to
override the action output of an ASPX page).

 

[Guest]

I think you're right about there being no way to properly handle the Postback situation in a ASP.NET page. I've gotten as far as hacking the output of one (using the Server.Execute with two parameters and changing the output), but I can never get the events of that page to fire properly or the IsPostback property to recognize the Postback. I've heard they're looking at changing this Postback issue in ASP.NET 2.0, but I've never seen anything official

I've looked at creating my own Page class before, but I'm not really sure how I would fit it into the existing ASP.NET framework. It seems like I could use something like the PageParser class to treat any extension as a "ASPX" page, but that class is not documented at all. I might play around with that later

For now, I'll continue to use the ASPX extension and handle everything with a HttpModule. I mainly wanted to use a different extension in case I wanted to put an ASPX page in my IIS application that doesn't use my "navigation framework"

Thanks for the help

 

[Guest]

Just in case you're curious Kevin, I found a solution using the PageParser class. Although the PageParser class is "not intended to be used", it's pretty simple it would seem

I did a search on that class name and found this post
http://www.dotnet247.com/247reference/msgs/14/71139.asp

That gave me some ideas (what he was doing was very similar)

So my handler that's registered for my extension now has a ProcessRequest method that looks like this

IHttpHandler handler = PageParser.GetCompiledPageInstance(PATHA, PATHB, context)
handler.ProcessRequest(context)
context.ApplicationInstance.CompleteRequest()

Where PATHA is an application root relative path (as a string) of their request. For instance, if my application root is http://localhost/Portal and I ask for http://localhost/Portal/Fred/Test.xyz, I would make PATHA "~/Fred/Test.xyz
And PATHB is the file path (as a string) to the file you want to load as an ASPX file. This file doesn't even need an ASPX extension (and if you don't want people browsing to it directly, eventually change its extension when you are finished editing it)

The only bad thing about this approach is the Page does not get cached. You could implement some caching yourself. In my case, the ASPX pages don't really need to be cached (just the controls they load dynamically), so it's not that big of a deal to me.

 

[Kevin Spencer]

Excellent!

--
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Just in case you're curious Kevin, I found a solution using the PageParser

class. Although the PageParser class is "not intended to be used", it's
pretty simple it would seem.

I did a search on that class name and found this post:
http://www.dotnet247.com/247reference/msgs/14/71139.aspx

That gave me some ideas (what he was doing was very similar).

So my handler that's registered for my extension now has a ProcessRequest method that looks like this:

IHttpHandler handler = PageParser.GetCompiledPageInstance(PATHA, PATHB, context);
handler.ProcessRequest(context);
context.ApplicationInstance.CompleteRequest();

Where PATHA is an application root relative path (as a string) of their

request. For instance, if my application root is http://localhost/Portal and
I ask for http://localhost/Portal/Fred/Test.xyz, I would make PATHA
"~/Fred/Test.xyz"

And PATHB is the file path (as a string) to the file you want to load as

an ASPX file. This file doesn't even need an ASPX extension (and if you
don't want people browsing to it directly, eventually change its extension
when you are finished editing it).

The only bad thing about this approach is the Page does not get cached.

You could implement some caching yourself. In my case, the ASPX pages don't
really need to be cached (just the controls they load dynamically), so it's
not that big of a deal to me.