ASP系列讲座(十九)管理会话
2000-07-30 09:47:06 来源:WEB开发网核心提示:成功开发 Web 应用程序的难题之一是在一次用户访问,即会话期间,ASP系列讲座(十九)管理会话,当用户在一个应用程序的页与页之间跳转的同时,维护用户信息,不同帧的多个请求的处理方式最终还要取决于用户 Web 浏览器的配置,某些 Web 浏览器可能不理会您的 .asp 文件的无会话配置,HTTP 是一种无状态协议,也就
成功开发 Web 应用程序的难题之一是在一次用户访问,即会话期间,当用户在一个应用程序的页与页之间跳转的同时,维护用户信息。HTTP 是一种无状态协议,也就是说,Web 服务器将某页的每次访问都当作相互无关的访问来处理;服务器不保留前一次访问的任何信息,即使访问就发生在当前访问的几秒钟之前。正因为这种不记忆以前访问的特性使得编写联机目录之类的应用程序很困难,此类应用程序可能需要跟踪用户在目录的不同页间跳转的同时曾选择过的目录项。
asp 提供了一个管理会话信息问题的独特方案。使用 ASP session 对象和由您的服务器生成的特殊用户 ID,您可以创建一个智能应用程序,该应用程序可以识别每个来访的用户并收集应用程序跟踪用户的首选项或选择内容所要用到的信息。
ASP 通过 HTTP cookie 设置用户 ID。HTTP cookie 是存储在用户浏览器上的小文件。因此,如果您正在为不支持 cookie 的浏览器创建应用程序,或者您的客户将浏览器设置为不接受 cookie,请不要使用 ASP 的会话管理功能。
您也可以编写在应用程序启动或结束时运行的脚本。
启动和结束会话
会话可以通过三种方式启动:
一个新用户请求访问一个 URL,该 URL 标识了某个应用程序中的 .asp 文件,并且该应用程序的 Global.asa 文件包含 Session_OnStart 过程。
用户在 Session 对象中存储了一个值。
用户请求了一个应用程序的 .asp 文件,并且该应用程序的 Global.asa 文件使用 <OBJECT> 标签创建带有会话作用域的对象的实例。
如果用户在指定时间内没有请求或刷新应用程序中的任何页,会话将自动结束。这段时间的默认值是 20 分钟。可以通过在 Internet 服务管理器中设置“应用程序选项”属性页中的“会话超时”属性改变应用程序的默认超时限制设置。应依据您的 Web 应用程序的要求和服务器的内存空间来设置此值。例如,如果您希望浏览您的 Web 应用程序的用户在每一页仅停留几分钟,就应该缩短会话的默认超时值。过长的会话超时值将导致打开的会话过多而耗尽您的服务器的内存资源。
对于一个特定的会话,如果您想设置一个小于默认超时值的超时值,可以设置 Session 对象的 Timeout 属性。例如,下面这段脚本将超时值设置为 5 分钟。
<% Session.Timeout = 5 %>
您也可以设置一个大于默认设置的超时值,Session.Timeout 属性决定超时值。
您也可以通过 Session 对象的 Abandon 方法显式结束一个会话。例如,在表格中提供一个“退出”按钮,将按钮的 ACTION 参数设置为包含下列命令的 .asp 文件的 URL 。
<% Session.Abandon %>
关于 SessionID 和 Cookie
当用户第一次请求给定的应用程序中的 .asp 文件时,ASP 生成一个 SessionID。SessionID 是由一个复杂算法生成的号码,它唯一标识每个用户会话。在新会话开始时,服务器将 Session ID 作为一个 cookie 存储在用户的 Web 浏览器中。
SessionID 与钥匙很相似,当会话期间用户与应用程序交互时,ASP 可以将用户信息存储在服务器的一个“保险箱”中。正象用钥匙能存取保险箱中物品一样,通过在 HTTP 请求标题中发送的用户 SessionID cookie,就能够对该“保险箱”中的内容进行访问。每当 ASP 收到一个页请求时,就检查 HTTP 请求标题,以获得 SessionID cookie。
在将 SessionID cookie 存储于用户的浏览器之后,即使用户请求了另一个 .asp 文件,或请求了运行在另一个应用程序中的 .asp 文件,ASP 仍会重用该 cookie 跟踪会话。与此相似,如果用户故意放弃会话或让会话超时,然后再请求另一个 .asp 文件,那么 ASP 将以同一个 cookie 开始新的会话。只有当服务器管理员重新启动服务器或用户重新启动 Web 浏览器时,此时存储在内存中的 SessionID 设置将被清除,用户将会获得新的 SessionID cookie。
通过重用 SessionID cookie,ASP 将发送给用户浏览器的 cookie 数量降为最低。另外,如果您决定您的 ASP 应用程序不需要会话管理,就可以不让 ASP 跟踪会话和向用户发送 SessionID 。
ASP 在以下情况下不发送会话的 cookie:
应用程序的会话状态被禁用。
ASP 页被定义为无会话,即该页包含 <%@ EnableSessionState=False %> 标记。
请注意,SessionID cookie 并不提供跟踪用户对某个 Web 站点的多次访问的永久方法。存储在服务器内存中的 SessionID 信息很容易丢失。如果想跟踪在很长时间内访问您的 Web 应用程序的用户,必须通过在用户的 Web 浏览器中存储一个专门的 cookie,并将 cookie 信息保存到数据库中来创建一个用户标识。
在 Session 对象中存储数据
Session 对象提供了一个可在其中存储信息的动态关联数组。您可以在 Session 对象中存储数值变量和对象变量。
通过对 Session 对象中的命名项赋值,可将变量存储在 Session 对象中。例如,以下命令将两个新变量存储在 Session 对象中:
<%
Session("FirstName") = "Jeff"
Session("LastName") = "Smith"
%>
通过访问该命名项可从 Session 对象中获取信息。例如,显示 Session("FirstName") 的当前值:
Welcome <%= Session("FirstName") %>
可以在 Session 对象中存储用户的首选项,然后通过访问首选项来决定将哪一页发送给用户。例如,可以允许用户在您的应用程序的第一页中指定纯文本版本的内容并将这一选择应用到用户此后对该应用程序的所有页的访问上。
<% If Session("ScreenResolution") = "Low" Then %>
This is the text version of the page.
<% Else %>
This is the multimedia version of the page.
<% End If %>
您也可以在 Session 对象中存储一个对象实例,但这样做会影响服务器的性能。
管理 Web Farm 的会话
ASP 会话信息存储在 Web 服务器中。浏览器必须向 Web 服务器请求页才能获得用来访问会话信息的脚本。在 Web Farm(其中许多 Web 服务器共同承担响应用户申请的责任)中,用户的请求并不总是被路由到同一个服务器,而是由一个被称为“负载平衡”进程的特殊软件对此 URL 站点的申请分配任意一个空闲的服务器。负载平衡进程使在 Web Farm 中保存会话信息变得更加困难。
为了在一个负载被平衡的站点上使用 ASP 会话管理,必须保证用户会话的所有请求都被定向到同一个 Web 服务器。一种做法是编写一个 Session_OnStart 过程,此过程使用 Response 对象将浏览器重定向到运行该用户会话的 Web 服务器。如果在您的应用程序页中的所有链接都是相对的,那么以后对某一页的所有请求都将被路由到同一个服务器。
例如,某用户要通过请求某一站点的通用 URL:http://www.microsoft.com 来访问一个应用程序。负载平衡进程将申请路由到服务器 server3.microsoft.com。ASP 在此服务器上生成了一个新的用户会话。在 Session_OnStart 过程中,浏览器被重定向给指定的服务器:
<% Response.Redirect("http://server3.microsoft.com/webapps/firstpage.asp") %>
浏览器将请求指定的页,并且以后的所有请求都将被路由到同一个服务器。
使用 Cookie
cookie 是 Web 服务器嵌在用户的 Web 浏览器中,用来代表用户的令牌。当下次同一浏览器请求一页时,它将发送从 Web 服务器收到的 cookie。 cookie 允许有一组信息与用户关联。 ASP 脚本使用 Response 和 Request 对象的 Cookies 集合,可以获取和设置 cookie 的值。
设置 cookie
要设置 cookie 的值,可使用 Response.Cookies。如果 cookie 不存在,Response.Cookies 将创建新的 cookie。例如,要向浏览器发送一个有关联值 ("Mars") 的 cookie 名 ("planet"),可使用下列命令,这些命令必须出现在您的 Web 页的 <HTML> 标记前:
<% Response.Cookies("planet")="Mars" %>
如果您只希望 cookie 在当前的用户会话中被使用,则只需向浏览器发送 cookie。但是,如果要在用户已经终止或重新启动浏览器之后确认用户,就必须强制浏览器将 cookie 存储在计算机的硬盘上。要保存 cookie,可使用 Response.Cookies 的 Expires 属性并将日期设置为此后的某一天:
<%
Response.Cookies("planet") = "Mars"
Response.Cookies("planet").Expires = "January 1, 1999"
%>
cookie 可有多个值;这样的 cookie 被称为一个带索引的 cookie。每个 cookie 值都被赋予一个关键字;您可以设置一个特定的 cookie 关键字的值。例如:
<% Response.Cookies("planet")("Mars")="SpaceMissions" %>
如果某个现有的 cookie 具有关键字值但 Response.Cookies 未指明一个关键字的名称,则该关键字值将被删除。类似的,如果某个现有的 cookie 没有关键字值但 Response.Cookies 指明了关键字的名称和值,则现有的 cookie 值将被删除,并生成新的 key-value 对。
获取 cookie
要获取 cookie 的值,可使用 Request.Cookies 集合。例如,如果用户的 HTTP 请求设置了 planet=Mars,则下列语句将获取值 Mars:
<%= Request.Cookies("planet") %>
相似的,要从带索引的 cookie 中获取关键字值,可使用关键字名。例如,如果用户发出下列的 HTTP 请求:
planet=Mars&Mars=SpaceMissions
下列脚本将返回值 SpaceMissions:
<%= Request.Cookies("planet")("Mars") %>
设置 cookie 路径
由 ASP 存储在用户的 Web 浏览器中的每个 cookie 都包含路径信息。当浏览器请求的文件的位置与在 cookie 中指定的路径相同时,浏览器自动将 cookie 转发给服务器。默认情况下,cookie 路径与包含最初生成 cookie 的 .asp 文件的应用程序名对应。例如,如果在名为 Userapplication 的应用程序中的 .asp 文件生成了一个 cookie,那么每当用户的 Web 浏览器在此应用程序中获取文件时,除其他在路径 /UserApplication 下的 cookie 外,浏览器还要将该 cookie 转发给服务器。
要给 cookie 声明一个不同于默认的应用程序路径的路径,可以使用 ASP 的 Response.Cookies 集合的 Path 属性。例如,下列脚本将路径 SalesApp/Customer/PRofiles/ 赋予名为 Purchases 的 cookie:
<%
Response.Cookies("Purchases") = "12"
Response.Cookies("Purchases").Expires = "January 1, 2001"
Response.Cookies("Purchases").Path = "/SalesApp/Customer/Profiles/"
%>
每当包含 Purchases cookie 的 Web 浏览器请求位于路径 /SalesApp/Customer/Profiles/ 或其子目录的文件时,浏览器将 cookie 转发给服务器。
许多 Web 浏览器,包括 Microsoft Internet Explorer 4.0 和 Netscape 浏览器,保留 cookie 路径的大小写。也就是说,如果一个被请求的文件的大小写与保留的 cookie 路径不同,那么浏览器是不会向服务器转发 cookie 的。例如,对于 ASP,虚拟目录 /TRAVEL 和 /travel 是相同的 ASP 应用程序,而对于保留 URL 的大小写的浏览器而言,/TRAVEL 和 /travel 则是两个不同的应用程序。应确保 .asp 文件的所有 URL 具有相同的大小写,以保证用户的浏览器能够转发存储的 cookie。
如果需要,可使用下列语句设置 cookie 路径,使得无论应用程序或路径是什么,只要用户的 Web 浏览器向您的服务器请求文件,就会转发 cookie :
Response.Cookies("Purchases").Path = "/"
但是,请注意,在不区分应用程序的情况下向服务器发送 cookie,如果 cookie 包含不应被指定应用程序以外的程序访问的敏感信息,就可能产生安全性问题。
不使用 cookie 而保留状态
并不是所有的浏览器都支持 cookie。即便使用支持 cookie 的浏览器,有些用户也可能喜欢关闭 cookie 支持。如果您的应用程序需要响应不支持 cookie 的浏览器,就必须使用 ASP 会话管理。
如果您不使用 ASP 会话管理,就必须编写您自己的机制以便在您的应用程序页之间传递信息。有两种常规的方法可完成该任务:
向 URL 的查询字符串添加参数。例如:
http://MyServer/MyApp/start.asp?name=Jeff
但是,某些浏览器,在表格被以 GET 方法提交的情况下会丢弃查询字符串中传递的显式参数。
向表格中添加隐含值。例如,以下的 HTML 表格包含一个隐含的控件。此控件在真正的表格中不出现,而且对用户的 Web 浏览器是不可见的。通过 HTTP POST 方法,表格除了传递用户提供的信息外,还传递用户标识。
<FORM METHOD="POST" ACTION="/scripts/inform.asp">
<INPUT TYPE="text" NAME="city" VALUE="">
<INPUT TYPE="text" NAME="country" VALUE ="">
<INPUT TYPE="hidden" NAME="userid" VALUE= <%=UserIDNum(i) %>
<INPUT TYPE="submit" VALUE="Enter">
本方法要求传输用户信息的所有链接目标被编码为 HTML 表格。
如果您当前没有使用 ASP 会话管理,请关闭您的应用程序会话支持。当会话启用时,ASP 向每个请求 ASP 页的浏览器发送 SessionID cookie。要关闭会话支持,可清除 Internet 服务管理器中的“应用程序选项”属性页中的“启用会话状态”复选框。
无会话的 ASP 页
ASP 也提供创建无会话页的功能,您可以使用该功能将会话的创建时间推迟到用户访问一个需要会话跟踪的 ASP 页时。
无会话页不执行以下功能:
执行 Session_OnStart 过程。
发送会话 ID cookie。
创建 Session 对象。
访问用 <OBJECT> 标记创建的内建会话对象或会话作用域对象。
与其他会话请求顺序执行。
要将 .asp 配置为无会话,可使用下列语句:
<%@ EnableSessionState=False %>
您应将此脚本置于 .asp 文件的第一行,位于其他脚本之前。默认情况下,若省略此标记,则启用会话跟踪。
无会话 ASP 页通过消除潜在的耗时会话操作,改善服务器的响应性能。例如,考虑以下情况,ASP 页包含某个帧集中的两个 HTML 帧,帧 1 和 帧 2。帧 1 包含一个执行复杂脚本的 .asp 文件,而帧 2 包含一个简单的 .html 文件。因为 ASP 顺序执行(即串行执行)会话请求,所以在帧 1 的脚本被执行之前,您将不会看到帧 2 的内容。但是,如果您将帧 1 设置为无会话,则 ASP 请求将不再被串行处理,浏览器不必等待执行完帧 1 的内容就可以处理帧 2 的内容。
但是,不同帧的多个请求的处理方式最终还要取决于用户 Web 浏览器的配置。某些 Web 浏览器可能不理会您的 .asp 文件的无会话配置,照样串行处理请求。
asp 提供了一个管理会话信息问题的独特方案。使用 ASP session 对象和由您的服务器生成的特殊用户 ID,您可以创建一个智能应用程序,该应用程序可以识别每个来访的用户并收集应用程序跟踪用户的首选项或选择内容所要用到的信息。
ASP 通过 HTTP cookie 设置用户 ID。HTTP cookie 是存储在用户浏览器上的小文件。因此,如果您正在为不支持 cookie 的浏览器创建应用程序,或者您的客户将浏览器设置为不接受 cookie,请不要使用 ASP 的会话管理功能。
您也可以编写在应用程序启动或结束时运行的脚本。
启动和结束会话
会话可以通过三种方式启动:
一个新用户请求访问一个 URL,该 URL 标识了某个应用程序中的 .asp 文件,并且该应用程序的 Global.asa 文件包含 Session_OnStart 过程。
用户在 Session 对象中存储了一个值。
用户请求了一个应用程序的 .asp 文件,并且该应用程序的 Global.asa 文件使用 <OBJECT> 标签创建带有会话作用域的对象的实例。
如果用户在指定时间内没有请求或刷新应用程序中的任何页,会话将自动结束。这段时间的默认值是 20 分钟。可以通过在 Internet 服务管理器中设置“应用程序选项”属性页中的“会话超时”属性改变应用程序的默认超时限制设置。应依据您的 Web 应用程序的要求和服务器的内存空间来设置此值。例如,如果您希望浏览您的 Web 应用程序的用户在每一页仅停留几分钟,就应该缩短会话的默认超时值。过长的会话超时值将导致打开的会话过多而耗尽您的服务器的内存资源。
对于一个特定的会话,如果您想设置一个小于默认超时值的超时值,可以设置 Session 对象的 Timeout 属性。例如,下面这段脚本将超时值设置为 5 分钟。
<% Session.Timeout = 5 %>
您也可以设置一个大于默认设置的超时值,Session.Timeout 属性决定超时值。
您也可以通过 Session 对象的 Abandon 方法显式结束一个会话。例如,在表格中提供一个“退出”按钮,将按钮的 ACTION 参数设置为包含下列命令的 .asp 文件的 URL 。
<% Session.Abandon %>
关于 SessionID 和 Cookie
当用户第一次请求给定的应用程序中的 .asp 文件时,ASP 生成一个 SessionID。SessionID 是由一个复杂算法生成的号码,它唯一标识每个用户会话。在新会话开始时,服务器将 Session ID 作为一个 cookie 存储在用户的 Web 浏览器中。
SessionID 与钥匙很相似,当会话期间用户与应用程序交互时,ASP 可以将用户信息存储在服务器的一个“保险箱”中。正象用钥匙能存取保险箱中物品一样,通过在 HTTP 请求标题中发送的用户 SessionID cookie,就能够对该“保险箱”中的内容进行访问。每当 ASP 收到一个页请求时,就检查 HTTP 请求标题,以获得 SessionID cookie。
在将 SessionID cookie 存储于用户的浏览器之后,即使用户请求了另一个 .asp 文件,或请求了运行在另一个应用程序中的 .asp 文件,ASP 仍会重用该 cookie 跟踪会话。与此相似,如果用户故意放弃会话或让会话超时,然后再请求另一个 .asp 文件,那么 ASP 将以同一个 cookie 开始新的会话。只有当服务器管理员重新启动服务器或用户重新启动 Web 浏览器时,此时存储在内存中的 SessionID 设置将被清除,用户将会获得新的 SessionID cookie。
通过重用 SessionID cookie,ASP 将发送给用户浏览器的 cookie 数量降为最低。另外,如果您决定您的 ASP 应用程序不需要会话管理,就可以不让 ASP 跟踪会话和向用户发送 SessionID 。
ASP 在以下情况下不发送会话的 cookie:
应用程序的会话状态被禁用。
ASP 页被定义为无会话,即该页包含 <%@ EnableSessionState=False %> 标记。
请注意,SessionID cookie 并不提供跟踪用户对某个 Web 站点的多次访问的永久方法。存储在服务器内存中的 SessionID 信息很容易丢失。如果想跟踪在很长时间内访问您的 Web 应用程序的用户,必须通过在用户的 Web 浏览器中存储一个专门的 cookie,并将 cookie 信息保存到数据库中来创建一个用户标识。
在 Session 对象中存储数据
Session 对象提供了一个可在其中存储信息的动态关联数组。您可以在 Session 对象中存储数值变量和对象变量。
通过对 Session 对象中的命名项赋值,可将变量存储在 Session 对象中。例如,以下命令将两个新变量存储在 Session 对象中:
<%
Session("FirstName") = "Jeff"
Session("LastName") = "Smith"
%>
通过访问该命名项可从 Session 对象中获取信息。例如,显示 Session("FirstName") 的当前值:
Welcome <%= Session("FirstName") %>
可以在 Session 对象中存储用户的首选项,然后通过访问首选项来决定将哪一页发送给用户。例如,可以允许用户在您的应用程序的第一页中指定纯文本版本的内容并将这一选择应用到用户此后对该应用程序的所有页的访问上。
<% If Session("ScreenResolution") = "Low" Then %>
This is the text version of the page.
<% Else %>
This is the multimedia version of the page.
<% End If %>
您也可以在 Session 对象中存储一个对象实例,但这样做会影响服务器的性能。
管理 Web Farm 的会话
ASP 会话信息存储在 Web 服务器中。浏览器必须向 Web 服务器请求页才能获得用来访问会话信息的脚本。在 Web Farm(其中许多 Web 服务器共同承担响应用户申请的责任)中,用户的请求并不总是被路由到同一个服务器,而是由一个被称为“负载平衡”进程的特殊软件对此 URL 站点的申请分配任意一个空闲的服务器。负载平衡进程使在 Web Farm 中保存会话信息变得更加困难。
为了在一个负载被平衡的站点上使用 ASP 会话管理,必须保证用户会话的所有请求都被定向到同一个 Web 服务器。一种做法是编写一个 Session_OnStart 过程,此过程使用 Response 对象将浏览器重定向到运行该用户会话的 Web 服务器。如果在您的应用程序页中的所有链接都是相对的,那么以后对某一页的所有请求都将被路由到同一个服务器。
例如,某用户要通过请求某一站点的通用 URL:http://www.microsoft.com 来访问一个应用程序。负载平衡进程将申请路由到服务器 server3.microsoft.com。ASP 在此服务器上生成了一个新的用户会话。在 Session_OnStart 过程中,浏览器被重定向给指定的服务器:
<% Response.Redirect("http://server3.microsoft.com/webapps/firstpage.asp") %>
浏览器将请求指定的页,并且以后的所有请求都将被路由到同一个服务器。
使用 Cookie
cookie 是 Web 服务器嵌在用户的 Web 浏览器中,用来代表用户的令牌。当下次同一浏览器请求一页时,它将发送从 Web 服务器收到的 cookie。 cookie 允许有一组信息与用户关联。 ASP 脚本使用 Response 和 Request 对象的 Cookies 集合,可以获取和设置 cookie 的值。
设置 cookie
要设置 cookie 的值,可使用 Response.Cookies。如果 cookie 不存在,Response.Cookies 将创建新的 cookie。例如,要向浏览器发送一个有关联值 ("Mars") 的 cookie 名 ("planet"),可使用下列命令,这些命令必须出现在您的 Web 页的 <HTML> 标记前:
<% Response.Cookies("planet")="Mars" %>
如果您只希望 cookie 在当前的用户会话中被使用,则只需向浏览器发送 cookie。但是,如果要在用户已经终止或重新启动浏览器之后确认用户,就必须强制浏览器将 cookie 存储在计算机的硬盘上。要保存 cookie,可使用 Response.Cookies 的 Expires 属性并将日期设置为此后的某一天:
<%
Response.Cookies("planet") = "Mars"
Response.Cookies("planet").Expires = "January 1, 1999"
%>
cookie 可有多个值;这样的 cookie 被称为一个带索引的 cookie。每个 cookie 值都被赋予一个关键字;您可以设置一个特定的 cookie 关键字的值。例如:
<% Response.Cookies("planet")("Mars")="SpaceMissions" %>
如果某个现有的 cookie 具有关键字值但 Response.Cookies 未指明一个关键字的名称,则该关键字值将被删除。类似的,如果某个现有的 cookie 没有关键字值但 Response.Cookies 指明了关键字的名称和值,则现有的 cookie 值将被删除,并生成新的 key-value 对。
获取 cookie
要获取 cookie 的值,可使用 Request.Cookies 集合。例如,如果用户的 HTTP 请求设置了 planet=Mars,则下列语句将获取值 Mars:
<%= Request.Cookies("planet") %>
相似的,要从带索引的 cookie 中获取关键字值,可使用关键字名。例如,如果用户发出下列的 HTTP 请求:
planet=Mars&Mars=SpaceMissions
下列脚本将返回值 SpaceMissions:
<%= Request.Cookies("planet")("Mars") %>
设置 cookie 路径
由 ASP 存储在用户的 Web 浏览器中的每个 cookie 都包含路径信息。当浏览器请求的文件的位置与在 cookie 中指定的路径相同时,浏览器自动将 cookie 转发给服务器。默认情况下,cookie 路径与包含最初生成 cookie 的 .asp 文件的应用程序名对应。例如,如果在名为 Userapplication 的应用程序中的 .asp 文件生成了一个 cookie,那么每当用户的 Web 浏览器在此应用程序中获取文件时,除其他在路径 /UserApplication 下的 cookie 外,浏览器还要将该 cookie 转发给服务器。
要给 cookie 声明一个不同于默认的应用程序路径的路径,可以使用 ASP 的 Response.Cookies 集合的 Path 属性。例如,下列脚本将路径 SalesApp/Customer/PRofiles/ 赋予名为 Purchases 的 cookie:
<%
Response.Cookies("Purchases") = "12"
Response.Cookies("Purchases").Expires = "January 1, 2001"
Response.Cookies("Purchases").Path = "/SalesApp/Customer/Profiles/"
%>
每当包含 Purchases cookie 的 Web 浏览器请求位于路径 /SalesApp/Customer/Profiles/ 或其子目录的文件时,浏览器将 cookie 转发给服务器。
许多 Web 浏览器,包括 Microsoft Internet Explorer 4.0 和 Netscape 浏览器,保留 cookie 路径的大小写。也就是说,如果一个被请求的文件的大小写与保留的 cookie 路径不同,那么浏览器是不会向服务器转发 cookie 的。例如,对于 ASP,虚拟目录 /TRAVEL 和 /travel 是相同的 ASP 应用程序,而对于保留 URL 的大小写的浏览器而言,/TRAVEL 和 /travel 则是两个不同的应用程序。应确保 .asp 文件的所有 URL 具有相同的大小写,以保证用户的浏览器能够转发存储的 cookie。
如果需要,可使用下列语句设置 cookie 路径,使得无论应用程序或路径是什么,只要用户的 Web 浏览器向您的服务器请求文件,就会转发 cookie :
Response.Cookies("Purchases").Path = "/"
但是,请注意,在不区分应用程序的情况下向服务器发送 cookie,如果 cookie 包含不应被指定应用程序以外的程序访问的敏感信息,就可能产生安全性问题。
不使用 cookie 而保留状态
并不是所有的浏览器都支持 cookie。即便使用支持 cookie 的浏览器,有些用户也可能喜欢关闭 cookie 支持。如果您的应用程序需要响应不支持 cookie 的浏览器,就必须使用 ASP 会话管理。
如果您不使用 ASP 会话管理,就必须编写您自己的机制以便在您的应用程序页之间传递信息。有两种常规的方法可完成该任务:
向 URL 的查询字符串添加参数。例如:
http://MyServer/MyApp/start.asp?name=Jeff
但是,某些浏览器,在表格被以 GET 方法提交的情况下会丢弃查询字符串中传递的显式参数。
向表格中添加隐含值。例如,以下的 HTML 表格包含一个隐含的控件。此控件在真正的表格中不出现,而且对用户的 Web 浏览器是不可见的。通过 HTTP POST 方法,表格除了传递用户提供的信息外,还传递用户标识。
<FORM METHOD="POST" ACTION="/scripts/inform.asp">
<INPUT TYPE="text" NAME="city" VALUE="">
<INPUT TYPE="text" NAME="country" VALUE ="">
<INPUT TYPE="hidden" NAME="userid" VALUE= <%=UserIDNum(i) %>
<INPUT TYPE="submit" VALUE="Enter">
本方法要求传输用户信息的所有链接目标被编码为 HTML 表格。
如果您当前没有使用 ASP 会话管理,请关闭您的应用程序会话支持。当会话启用时,ASP 向每个请求 ASP 页的浏览器发送 SessionID cookie。要关闭会话支持,可清除 Internet 服务管理器中的“应用程序选项”属性页中的“启用会话状态”复选框。
无会话的 ASP 页
ASP 也提供创建无会话页的功能,您可以使用该功能将会话的创建时间推迟到用户访问一个需要会话跟踪的 ASP 页时。
无会话页不执行以下功能:
执行 Session_OnStart 过程。
发送会话 ID cookie。
创建 Session 对象。
访问用 <OBJECT> 标记创建的内建会话对象或会话作用域对象。
与其他会话请求顺序执行。
要将 .asp 配置为无会话,可使用下列语句:
<%@ EnableSessionState=False %>
您应将此脚本置于 .asp 文件的第一行,位于其他脚本之前。默认情况下,若省略此标记,则启用会话跟踪。
无会话 ASP 页通过消除潜在的耗时会话操作,改善服务器的响应性能。例如,考虑以下情况,ASP 页包含某个帧集中的两个 HTML 帧,帧 1 和 帧 2。帧 1 包含一个执行复杂脚本的 .asp 文件,而帧 2 包含一个简单的 .html 文件。因为 ASP 顺序执行(即串行执行)会话请求,所以在帧 1 的脚本被执行之前,您将不会看到帧 2 的内容。但是,如果您将帧 1 设置为无会话,则 ASP 请求将不再被串行处理,浏览器不必等待执行完帧 1 的内容就可以处理帧 2 的内容。
但是,不同帧的多个请求的处理方式最终还要取决于用户 Web 浏览器的配置。某些 Web 浏览器可能不理会您的 .asp 文件的无会话配置,照样串行处理请求。
[]
更多精彩
赞助商链接