Quick question: Is it possible to insert an http handler into the pipeline for a classic .asp page, so that the .asp page is processed as normal, but you have access to the request and response before and after classic .asp processing?
It is not possible to do it the way you describe, which looks like this:
Request --> Pre-handler | Handler | Post-handler --> Response
page.asp by ASP.NET | by ASP | by ASP.NET
The ASP runtime is an ISAPI executable that the ASP.NET runtime cannot launch. That is, your ASP.NET handler code (maybe an .ashx handler in this situation) cannot create an instance of the ASP runtime and then pass it the original request for processing,
and then get hold of the output.
What you can do however is have your ASP.NET handler issue a full new web request. Say that you have updated IIS so that requests for .asp extensions are mapped to ASP.NET. You then add a new extension (say .old) which is mapped to ASP. Your ASP.NET handler
receives a request for page.asp, and then issues a new web request for the page named page.old, which will be passed by IIS to ASP. Your ASP.NET handler will get the response from ASP. Then, any post-handler processing (such as filtering that HTML response)
can occur. This process looks like this:
Request --> Pre-handler | Handler | Post-handler --> Response
page.asp by ASP.NET | by ASP.NET | by ASP.NET
| ^
| |
-------------------- --------------------
| |
----> Request --> Handler --> Response ----
page.old by ASP
To learn how your own ASP.NET handler can issue a new request, please refer to the documentation for the
WebClient class. While that would be a bit slow (as the user must wait for two requests to be processed), you can cache the result so that this is a one-time-only expensive operation. You could then add a file-dependency to that cached
output, so that should the page.old file change, this will remove ASP.NET's cached version of the page. Then, when the page is next requested, ASP.NET goes through the two-request cycle, and again caches the output with a file dependency.
Many thanks, I think that is the best response I have ever seen to a question posted on a forum, ever.
My situation right now is that I want to apply page caching by storing a classic asp response (and injecting the cached page into the response stream the second time round) much like ASP.NET caching.
Am I correct in thinking that by using webclient etc to reissue the response I will loose all the session variables,cookies etc as it is a new request (and from a different client etc) and I would have to map those across to the new session?
Am I correct in thinking that by using webclient etc to reissue the response I will loose all the session variables,cookies etc as it is a new request (and from a different client etc) and I would have to map those across to the new session?
I have not had occasion to do this myself, but I will give you my best guess.
When your ASP.NET handler receives the request for page.asp, the cookie is not a little thing that is somehow "attached" to the original request. (I am not being condescending here, because I
do tend to visualise the cookie as an attachment.) Rather, the cookie value is a part of the header information of that request. Now, when your ASP.NET handler prepares the new web request, you do have the option of constructing the header information.
That is, your ASP.NET page looks at the header collection of the request for page.asp, and then reconstructs this same information in the web request for page.old. Effectively, it is passing the cookie value on to the ASP handler.
In the same way you can inspect form name-value collection of the original request for page.asp, and reconstruct it for the web request for page.old. Further still, you can grab the query string that was attached to the request for page.asp, and add to the
request for page.old.
That should, I think, be all you need for the ASP handler to think that the incoming request came from the web surfer sitting at her computer, and not reissued from a machine. In this case, all session and other state features should be maintained. The operative
phrase there is "I think." I don't actually know, as I have never had need to do this.
However, MSDN has some information on sharing state between an ASP.NET application and an ASP application. The same sections of MSDN may provide additional information on how to get the two environments working together.
Many thanks for the response, I think I'm pretty much in the situation that I can just use classic .asp for this purpose, Ill let you know if I find a godd way of doing this with asp.net.
jameswestgat...
Member
15 Points
3 Posts
HttpHandlers and Classic ASP
Dec 30, 2005 07:01 PM|LINK
Quick question: Is it possible to insert an http handler into the pipeline for a classic .asp page, so that the .asp page is processed as normal, but you have access to the request and response before and after classic .asp processing?
Many thanks
James
SomeNewKid
All-Star
45894 Points
8027 Posts
Re: HttpHandlers and Classic ASP
Dec 30, 2005 08:03 PM|LINK
It is not possible to do it the way you describe, which looks like this:
Request --> Pre-handler | Handler | Post-handler --> Response
page.asp by ASP.NET | by ASP | by ASP.NET
The ASP runtime is an ISAPI executable that the ASP.NET runtime cannot launch. That is, your ASP.NET handler code (maybe an .ashx handler in this situation) cannot create an instance of the ASP runtime and then pass it the original request for processing, and then get hold of the output.
What you can do however is have your ASP.NET handler issue a full new web request. Say that you have updated IIS so that requests for .asp extensions are mapped to ASP.NET. You then add a new extension (say .old) which is mapped to ASP. Your ASP.NET handler receives a request for page.asp, and then issues a new web request for the page named page.old, which will be passed by IIS to ASP. Your ASP.NET handler will get the response from ASP. Then, any post-handler processing (such as filtering that HTML response) can occur. This process looks like this:
Request --> Pre-handler | Handler | Post-handler --> Response
page.asp by ASP.NET | by ASP.NET | by ASP.NET
| ^
| |
-------------------- --------------------
| |
----> Request --> Handler --> Response ----
page.old by ASP
To learn how your own ASP.NET handler can issue a new request, please refer to the documentation for the WebClient class. While that would be a bit slow (as the user must wait for two requests to be processed), you can cache the result so that this is a one-time-only expensive operation. You could then add a file-dependency to that cached output, so that should the page.old file change, this will remove ASP.NET's cached version of the page. Then, when the page is next requested, ASP.NET goes through the two-request cycle, and again caches the output with a file dependency.
Does that help you?
jameswestgat...
Member
15 Points
3 Posts
Re: HttpHandlers and Classic ASP
Dec 31, 2005 12:10 AM|LINK
Many thanks, I think that is the best response I have ever seen to a question posted on a forum, ever.
My situation right now is that I want to apply page caching by storing a classic asp response (and injecting the cached page into the response stream the second time round) much like ASP.NET caching.
Am I correct in thinking that by using webclient etc to reissue the response I will loose all the session variables,cookies etc as it is a new request (and from a different client etc) and I would have to map those across to the new session?
Many thanks again
James
SomeNewKid
All-Star
45894 Points
8027 Posts
Re: HttpHandlers and Classic ASP
Dec 31, 2005 10:33 PM|LINK
When your ASP.NET handler receives the request for page.asp, the cookie is not a little thing that is somehow "attached" to the original request. (I am not being condescending here, because I do tend to visualise the cookie as an attachment.) Rather, the cookie value is a part of the header information of that request. Now, when your ASP.NET handler prepares the new web request, you do have the option of constructing the header information. That is, your ASP.NET page looks at the header collection of the request for page.asp, and then reconstructs this same information in the web request for page.old. Effectively, it is passing the cookie value on to the ASP handler.
In the same way you can inspect form name-value collection of the original request for page.asp, and reconstruct it for the web request for page.old. Further still, you can grab the query string that was attached to the request for page.asp, and add to the request for page.old.
That should, I think, be all you need for the ASP handler to think that the incoming request came from the web surfer sitting at her computer, and not reissued from a machine. In this case, all session and other state features should be maintained. The operative phrase there is "I think." I don't actually know, as I have never had need to do this.
However, MSDN has some information on sharing state between an ASP.NET application and an ASP application. The same sections of MSDN may provide additional information on how to get the two environments working together.
jameswestgat...
Member
15 Points
3 Posts
Re: HttpHandlers and Classic ASP
Jan 03, 2006 04:04 PM|LINK
Best wishes
James