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.
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.