没看懂的是这段英文On execution of the Page_Load function, the TransferSession function gets called, which consumes the XML data from the ASPClassicSession.asp page, creates the Session contents in ASP.NET, and redirects the user to the specified destination page. Gathering the XML data is not as easy as it sounds. Since the call from the client browser is going to the server, the server is then making the request for the ASP Classic page to generate the XML. The ASP.NET application does not share your ASP Classic Session State. The relationship between your browser and IIS is dependent on specific headers being passed back and forth. In this example we have ASP.NET gather the headers from the client request, and create our own socket connection to the server using our customized headers to create the illusion that we are the client browser making the request. ASP Classic accepts the request and gladly returns the desired results. With all applications, you must know your data. The current implementation of this solution will not handle objects or arrays. It would not be difficult to customize the solution to work with specific objects if you know how to detect and rebuild them. Security This is a subject often skipped due to lack of education or lack of time. Security is out of the scope of this article, but I will present some ideas. This solution has both inherent security and the ability to apply additional security with minimal effort. Inherent security exists in that execution occurs on the server-side. A user cannot create their own form or edit post variables to choose a different User ID or security level to transfer to. What if you don’t want your users to have the ability to request the XML feed and see their session variables? Simply identify servers, such as the ASP.NET web servers, that are allowed to request the file and authorize them on your page. A visual should shed some light on this. I will modify the ASP Classic code from above:
要不，用金山快译翻译一下。
[转载]asp和asp.net共享session解决办法
www.chinacs.net 2004-05-27 中文C#技术站在原有的asp程序中用asp.net添加功能模块，共享SESSIONs是一个难点，下面介绍一种较为简洁的方法，可以在asp和asp.net中共享session会话。登录页面使用C#重新创建，在成功登录后执行语句：Response.Write("<script language='javascript'>window.open('ASPXTOASP.aspx','new');</script>");打开aspxtoasp.aspx页面，action设为aspxtoasp.asp，即可将session值post到asp页面，因为是单向传递，不用在其他页面重复执行动作，经测试，传递成功！ Aspxtoasp.aspx代码如下：<script language="C#" runat="server"> Response.Write( "<form name=t id=t action=ASPXTOASP.asp method=post>" ); foreach(object it in Session.Contents) { Response.Write("<input type=hidden name=" + it.ToString()); Response.Write( " value=" + Session[it.ToString()].ToString() + " >"); }Response.Write("</FORM>");Response.Write("<scr" + "ipt>t.submit();</scr" + "ipt>"); </script> Aspxtoasp.asp代码如下：<%for i=1 to Request.Form.Count Session(Request.Form.Key(i))=Request.Form(i)nextResponse.End %> <script language="javascript">window.close();</script>
>>原作者:aoyux >>来源:不详
俄tigerwen01(小虎)(编程艺术化)
这个方法也很好，再帮我分析一下那篇英文文档：）
Gathering the XML data is not as easy as it sounds. Since the call from the client browser is going to the server, the server is then making the request for the ASP Classic page to generate the XML. The ASP.NET application does not share your ASP Classic Session State. The relationship between your browser and IIS is dependent on specific headers being passed back and forth. In this example we have ASP.NET gather the headers from the client request, and create our own socket connection to the server using our customized headers to create the illusion that we are the client browser making the request. ASP Classic accepts the request and gladly returns the desired results. With all applications, you must know your data. The current implementation of this solution will not handle objects or arrays. It would not be difficult to customize the solution to work with specific objects if you know how to detect and rebuild them.
Security
This is a subject often skipped due to lack of education or lack of time. Security is out of the scope of this article, but I will present some ideas. This solution has both inherent security and the ability to apply additional security with minimal effort.
Inherent security exists in that execution occurs on the server-side. A user cannot create their own form or edit post variables to choose a different User ID or security level to transfer to. What if you don’t want your users to have the ability to request the XML feed and see their session variables? Simply identify servers, such as the ASP.NET web servers, that are allowed to request the file and authorize them on your page. A visual should shed some light on this. I will modify the ASP Classic code from above: