具体来说cookie机制采用的是在客户端保持状态的方案,而session机制采用的是在服务器端保持状态的方案。同时我们也看到,由于采用服务器端保持状态的方案在客户端也需要保存一个标识,所以session机制可能需要借助于cookie机制来达到保存标识的目的,但实际上它还有其他选择。
cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的,服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie,如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置,则把该cookie附在请求资源的HTTP请求头上发送给服务器。
Cookies如何存储
Cookies保存在用户的本地机器上,不同的浏览器存储在不同的文件夹中,并且按照域名分别保存。即网站之间的Cookies不会彼此覆盖。
IE浏览器的用户可以通过在本地的文档中找到Cookies的txt文件, 不同操作系统的位置不同,windows server 2003/xp都保存在:
C:Documents and SettingsAdministratorCookies 文件夹下。
其中名称txt按照域名保存,比如localhost域下的cookies为:
administrator@localhost[1].txt 或者 administrator@localhost[2].txt
其中后面的[1]和[2]是随着每次保存交替变化的。
3.Cookies如何传递
Cookies的信息是在Web服务器和浏览器之间传递的。保存在Http请求中。
(1)请求页面
在请求一个页面的Http头中,会将属于此页面的本地Cookies信息加在Http头中,注意下面加粗的部分:
GET /Cookies/Test.aspx HTTP/1.1
Host: localhost:1335
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; zh-CN; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 GTB5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: My.Common.TestCookieInfo=Pkid=999&TestValue=aaabbbcccdddeee (2)页面响应
如果页面要求写入Cookies信息,则返回的Http如下,注意加粗的部分:
HTTP/1.x 200 OK
Server: ASP.NET Development Server/9.0.0.0
Date: Thu, 06 Aug 2009 03:40:59 GMT
X-AspNet-Version: 2.0.50727
Set-Cookie: My.Common.TestCookieInfo=Pkid=999&TestValue=aaabbbcccdddeee; expires=Fri, 07-Aug-2009 03:40:59 GMT; path=/
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 558
Connection: Close 4.Cookies如何查看
(1)查看Cookies的txt文件
IE用户可以直接查看Cookies的txt文件。
比如:C:Documents and SettingsAdministratorCookiesadministrator@localhost[1].txt
session机制
Session是什么呢?简单来说就是服务器给客户端的一个编号。当一台WWW服务器运行时,可能有若干个用户浏览正在运正在这台服务器上的网站。当每个用户首次与这台WWW服务器建立连接时,他就与这个服务器建立了一个Session,同时服务器会自动为其分配一个SessionID,用以标识这个用户的唯一身份。这个SessionID是由WWW服务器随机产生的一个由24个字符组成的字符串,我们会在下面的实验中见到它的实际样子。
这个唯一的SessionID是有很大的实际意义的。当一个用户提交了表单时,浏览器会将用户的SessionID自动附加在HTTP头信息中,(这是浏览器的自动功能,用户不会察觉到),当服务器处理完这个表单后,将结果返回给SessionID所对应的用户。试想,如果没有SessionID,当有两个用户同时进行注册时,服务器怎样才能知道到底是哪个用户提交了哪个表单呢。当然,SessionID还有很多其他的作用,我们会在后面提及到。
除了SessionID,在每个Session中还包含很多其他信息。但是对于编写ASP或ASP.NET的程序与来说,最有用的还是可以通过访问ASP/ASP.NET的内置Session对象,为每个用户存储各自的信息。例如我们想了解一下访问我们网站的用户浏览了几个页面,我们可能在用户可能访问到每个的页面中加入:
代码如下 | 复制代码 |
<% If Session("PageViewed") = ""Then Session("PageViewed") = 1 Else Session("PageViewed") = Session("PageViewed") + 1 End If %> |
通过以下这句话可以让用户得知自己浏览了几个页面:
代码如下 | 复制代码 |
<% Response.Write("You have viewed " & Session("PageViewed") & " pages") %> |
可能有些有些读者会问:这个看似像是数组的Session(“..”)是哪里来的?需要我定义吗?实际上,这个Session对象是具有ASP解释能力的的WWW服务器的内建对象。也就是说ASP的系统中已经给你定义好了这个对象,你只需要使用就行了。其中Session(“..”)中的..就好像变量名称,Session(“..”)=$$$中的$$$就是变量的值了。你只需要写上句话,在这个用户的每个页面中都可以访问..变量中的值了。
其实ASP一共内建了7个对象,有Session、Application、Cookie、Response、Request、Server等。在其他的服务器端脚本语言如JSP、PHP等中也有其类似的对象,只是叫法或者使用方法上不太一样。
ASP Session的功能的缺陷
目前ASP的开发人员都正在使用Session这一强大的功能,但是在他们使用的过程中却发现了ASP Session有以下缺陷:
进程依赖性:ASP Session状态存于IIS的进程中,也就是inetinfo.exe这个程序。所以当inetinfo.exe进程崩溃时,这些信息也就丢失。另外,重起或者关闭IIS服务都会造成信息的丢失。
Session状态使用范围的局限性:刚一个用户从一个网站访问到另外一个网站时,这些Session信息并不会随之迁移过去。例如:新浪网站的WWW服务器可能不止一个,一个用户登录之后要去各个频道浏览,但是每个频道都在不同的服务器上,如果想在这些WWW服务器共享Session信息怎么办呢?
Cookie的依赖性:实际上客户端的Session信息是存储与Cookie中的,如果客户端完全禁用掉了Cookie功能,他也就不能享受到了Session提供的功能了。
鉴于ASP Session的以上缺陷,微软的设计者们在设计开发 ASP.NET Session时进行了相应的改进,完全克服了以上缺陷,使得ASP.NET Session成为了一个更加强大的功能。
Web.config文件中的Session配置信息
打开某个应用程序的配置文件Web.config后,我们会发现以下这段:
代码如下 | 复制代码 |
stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /> |
这一段就是配置应用程序是如何存储Session信息的了。我们以下的各种操作主要是针对这一段配置展开。让我们先看看这一段配置中所包含的内容的意思。sessionState节点的语法是这样的:
代码如下 | 复制代码 |
|
经常被使用的一种技术叫做URL重写,就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器。比如:
代码如下 | 复制代码 |
实际上这种技术可以简单的用对action应用URL重写来代替。