Cookie和Session专题知识

Cookie和Session专题知识
2010年08月28日
　　转载于： http://www.tzlink.com/info/show.php?aid=8986
　　一、cookie机制和session机制的区别
　　具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。
　　同时我们也看到，由于才服务器端保持状态的方案在客户端也需要保存一个标识，所以session
　　机制可能需要借助于cookie机制来达到保存标识的目的，但实际上还有其他选择
　　二、会话cookie和持久cookie的区别
　　如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
　　如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。
　　存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。
　　三、如何利用实现自动登录
　　当用户在某个网站注册后，就会收到一个惟一用户ID的cookie。客户后来重新连接时，这个
　　用户ID会自动返回，服务器对它进行检查，确定它是否为注册用户且选择了自动登录，从而使用户务需给出明确的用户名和密码，就可以访问服务器上的资源。
　　四、如何根据用户的爱好定制站点
　　网站可以使用cookie记录用户的意愿。对于简单的设置，网站可以直接将页面的设置存储在cookie中完成定制。然而对于更复杂的定制，网站只需仅将一个惟一的标识符发送给用户，由服务器端的数据库存储每个标识符对应的页面设置。
　　五、cookie的发送
　　1.创建Cookie对象
　　2.设置最大时效
　　3.将Cookie放入到HTTP响应报头
　　如果你创建了一个cookie，并将他发送到浏览器，默认情况下它是一个会话级别的cookie:存储在浏览器的内存中，用户退出浏览器之后被删除。如果你希望浏览器将该cookie存储在磁盘上，则
　　需要使用maxAge，并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该cookie。
　　发送cookie需要使用HttpServletResponse的addCookie方法，将cookie插入到一个Set-Cookie HTTP请 求报头中。由于这个方法并不修改任何之前指定的Set-Cookie报头，而是创建新的报头，因此我们将这个方法称为是addCookie，而非 setCookie。同样要记住响应报头必须在任何文档内容发送到客户端之前设置。
　　六、cookie的读取
　　1.调用request.getCookie
　　要获取有浏览器发送来的cookie，需要调用HttpServletRequest的getCookies方法，这个调用返回Cookie对象的数组，对应由HTTP请求中Cookie报头输入的值。
　　2.对数组进行循环，调用每个cookie的getName方法，直到找到感兴趣的cookie为止
　　cookie与你的主机(域)相关，而非你的servlet或JSP页面。因而，尽管你的servlet可能只发送了单个cookie，你也可能会得到许多不相关的cookie。
　　例如：
　　String cookieName = "userID";
　　Cookie cookies[] = request.getCookies();
　　if (cookies!=null){
　　for(int i=0;i循环中检索指定名字的cookie是否存在以及对应的值是否正确
　　C.如果是则退出循环并设置区别标识
　　D.根据区别标识判断用户是否为初访者从而进行不同的操作
　　八、使用cookie检测初访者的常见错误
　　不能仅仅因为cookie数组中不存在在特定的数据项就认为用户是个初访者。如果cookie数组为null，客户可能是一个初访者，也可能是由于用户将cookie删除或禁用造成的结果。
　　但是，如果数组非null,也不过是显示客户曾经到过你的网站或域，并不能说明他们曾经访问过你的servlet。其它servlet、JSP页面以及非Java Web应用都可以设置cookie，依据路径的设置，其中的任何cookie都有可能返回给用户的浏览器。
　　正确的做法是判断cookie数组是否为空且是否存在指定的Cookie对象且值正确。
　　九、使用cookie属性的注意问题
　　属性是从服务器发送到浏览器的报头的一部分；但它们不属于由浏览器返回给服务器的报头。 
　　因此除了名称和值之外，cookie属性只适用于从服务器输出到客户端的cookie；服务器端来自于浏览器的cookie并没有设置这些属性。 
　　因而不要期望通过request.getCookies得到的cookie中可以使用这个属性。这意味着，你不能仅仅通过设置cookie的最大时效，发 出它，在随后的输入数组中查找适当的cookie,读取它的值，修改它并将它存回Cookie，从而实现不断改变的cookie值。
　　十、如何使用cookie记录各个用户的访问计数
　　1.获取cookie数组中专门用于统计用户访问次数的cookie的值
　　2.将值转换成int型
　　3.将值加1并用原来的名称重新创建一个Cookie对象
　　4.重新设置最大时效
　　5.将新的cookie输出
　　十一、session在不同环境下的不同含义
　　session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话是从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。
　　然而当session一词与网络协议相关联时，它又往往隐含了"面向连接"和/或"保持状态"这样两个含义。
　　session在Web开发环境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器端之间保持状态的解决方案。有时候Session也用来指这种解决方案的存储结构。
　　十二、session的机制
　　session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
　　但程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识－称为session id,如果已经包含一个session id则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用(如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为 地在请求的URL后面附加上一个JSESSION的参数)。
　　如果客户请求不包含session id，则为此客户创建一个session并且生成一个与此session相关联的session id，这个session id将在本次响应中返回给客户端保存。
　　十三、保存session id的几种方式
　　A．保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
　　B．由于cookie可以被人为的禁止，必须有其它的机制以便在cookie被禁止时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL重写，就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终 保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。
　　C．另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。
　　十四、session什么时候被创建
　　一个常见的错误是以为session在有客户端访问时就被创建，然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true)这样的语句时才会被创建。
　　十五、session何时被删除
　　session在下列情况下被删除：
　　A．程序调用HttpSession.invalidate()
　　B．距离上一次收到客户端发送的session id时间间隔超过了session的最大有效时间
　　C．服务器进程被停止
　　再次注意关闭浏览器只会使存储在客户端浏览器内存中的session cookie失效，不会使服务器端的session对象失效。
　　十六、URL重写有什么缺点
　　对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL。每个引用你的站点的URL，以及那些返回给用户的URL(即使通过间接手段，比如服务器重定向中的Location字段)都要添加额外的信息。
　　这意味着在你的站点上不能有任何静态的HTML页面(至少静态页面中不能有任何链接到站点动态页面的链接)。因此，每个页面都必须使用servlet或 JSP动态生成。即使所有的页面都动态生成，如果用户离开了会话并通过书签或链接再次回来，会话的信息都会丢失，因为存储下来的链接含有错误的标识信息－ 该URL后面的SESSION ID已经过期了。 
　　十七、使用隐藏的表单域有什么缺点
　　仅当每个页面都是有表单提交而动态生成时，才能使用这种方法。单击常规的超文本链接并不产生表单提交，因此隐藏的表单域不能支持通常的会话跟踪，只能用于一系列特定的操作中，比如在线商店的结账过程
　　十八、会话跟踪的基本步骤
　　1．访问与当前请求相关的会话对象
　　2．查找与会话相关的信息
　　3．存储会话信息
　　4．废弃会话数据
　　十九、getSession()/getSession(true)、getSession(false)的区别
　　getSession()/getSession(true)：当session存在时返回该session，否则新建一个session并返回该对象
　　getSession(false)：当session存在时返回该session，否则不会新建session，返回null
　　二十、如何将信息于会话关联起来
　　setAttribute会替换任何之前设定的值；如果想要在不提供任何代替的情况下移除某个值，则应使用removeAttribute。这个方法会触发所有实现了HttpSessionBindingListener接口的值的valueUnbound
　　方法。
　　二十一、会话属性的类型有什么限制吗
　　通常会话属性的类型只要是Object就可以了。除了null或基本类型，如int,double,boolean。
　　如果要使用基本类型的值作为属性，必须将其转换为相应的封装类对象
　　二十二、如何废弃会话数据
　　A．只移除自己编写的servlet创建的数据：
　　调用removeAttribute("key")将指定键关联的值废弃
　　B．删除整个会话(在当前Web应用中)：
　　调用invalidate，将整个会话废弃掉。这样做会丢失该用户的所有会话数据，而非仅仅由我们
　　servlet或JSP页面创建的会话数据
　　C．将用户从系统中注销并删除所有属于他(或她)的会话
　　调用logOut，将客户从Web服务器中注销，同时废弃所有与该用户相关联的会话(每个Web应用至多一个)。这个操作有可能影响到服务器上多个不同的Web应用
　　二十三、使用isNew来判断用户是否为新旧用户的错误做法
　　public boolean isNew()方法如果会话尚未和客户程序(浏览器)发生任何联系，则这个方法返回true，这一般是因为会话是新建的，不是由输入的客户请求所引起的。
　　但如果isNew返回false，只不过是说明他之前曾经访问该Web应用，并不代表他们曾访问过我们的servlet或JSP页面。
　　因为session是与用户相关的，在用户之前访问的每一个页面都有可能创建了会话。因此isNew为false只能说用户之前访问过该Web应用，session可以是当前页面创建，也可能是由用户之前访问过的页面创建的。
　　正确的做法是判断某个session中是否存在某个特定的key且其value是否正确
　　二十四、Cookie的过期和Session的超时有什么区别
　　会话的超时由服务器来维护，它不同于Cookie的失效日期。首先，会话一般基于驻留内存的cookie
　　不是持续性的cookie，因而也就没有截至日期。即使截取到JSESSIONID cookie，并为它设定一个失效日期发送出去。浏览器会话和服务器会话也会截然不同。
　　二十五、session cookie和session对象的生命周期是一样的吗
　　当用户关闭了浏览器虽然session cookie已经消失，但session对象仍然保存在服务器端
　　二十六、是否只要关闭浏览器，session就消失了
　　程序一般都是在用户做log off的时候发个指令去删除session，然而浏览器从来不会主动在关闭之前通知服务器它将要被关闭，因此服务器根本不会有机会知道浏览器已经关闭。服务器会一直保留这个会话对象直到它处于非活动状态超过设定的间隔为止。
　　之所以会有这种错误的认识，是因为大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接到服务器时也就无法找到原来的session。
　　如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求报头，把原来的session id发送到服务器，则再次打开浏览器仍然能够找到原来的session。
　　恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为session设置了一个失效时间，当距离客户上一次使用session的时间超过了这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。
　　由此我们可以得出如下结论：
　　关闭浏览器，只会是浏览器端内存里的session cookie消失，但不会使保存在服务器端的session对象消失，同样也不会使已经保存到硬盘上的持久化cookie消失。 
　　二十七、打开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
　　通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的session id，这样我们信息共享的目的就达不到了。
　　此时我们可以先把session id保存在persistent cookie中(通过设置session的最大有效时间)，然后在新窗口中读出来，就可以得到上一个窗口的session id了，这样通过session cookie和persistent cookie的结合我们就可以实现了跨窗口的会话跟踪。
　　二十八、如何使用会话显示每个客户的访问次数
　　由于客户的访问次数是一个整型的变量，但session的属性类型中不能使用int，double，boolean等基本类型的变量，所以我们要用到这些基本类型的封装类型对象作为session对象中属性的值
　　但像Integer是一种不可修改(Immutable)的数据结构：构建后就不能更改。这意味着每个请求都必须创建新的Integer对象，之后使用setAttribute来代替之前存在的老的属性的值。例如：
　　HttpSession session = request.getSession();
　　SomeImmutalbeClass value = (SomeImmutableClass)session.getAttribute("SomeIden tifier");
　　if (value= =null){
　　value = new SomeImmutableClass(…); // 新创建一个不可更改对象
　　}else{
　　value = new SomeImmutableClass(calculatedFrom(value)); // 对value重新计算后创建新的对象
　　}
　　session.setAttribute("someIdentifier",value); // 使用新创建的对象覆盖原来的老的对象
　　二十九、如何使用会话累计用户的数据
　　使用可变的数据结构，比如数组、List、Map或含有可写字段的应用程序专有的数据结构。通过这种方式，除非首次分配对象，否则不需要调用setAttribute。例如
　　HttpSession session = request.getSession();
　　SomeMutableClass value = (SomeMutableClass)session.getAttribute("someIdenti fier");
　　if(value = = null){
　　value = new SomeMutableClass(…);
　　session.setAttribute("someIdentifier",value);
　　}else{
　　value.updateInternalAttribute(…); // 如果已经存在该对象则更新其属性而不需重新设置属性
　　}
　　三十、不可更改对象和可更改对象在会话数据更新时的不同处理
　　不可更改对象因为一旦创建之后就不能更改，所以每次要修改会话中属性的值的时候，都需要
　　调用setAttribute("someIdentifier",newValue)来代替原有的属性的值，否则属性的值不会被更新
　　可更改对象因为其自身一般提供了修改自身属性的方法，所以每次要修改会话中属性的值的时
　　候，只要调用该可更改对象的相关修改自身属性的方法就可以了。这意味着我们就不需要调
　　用setAttribute方法了
　　（2）
　　对SESSION的争论好象一直没有停止过，不过幺麽能理解SESSION的人应该占90以上。 
　　但还是讲讲，别嫌老~
　　有一些人赞成用SESSION，有一些人不赞成。但这个问题到底要怎么说。不妨听听我的看法
　　如果有错误请不要朝丢东西，金条和硬币除外。
　　有些人应该知道我是做江湖程序的，而江湖程序做看中的就是效率，但这里不谈设计，而
　　从一些比较实际的角度看SESSION。
　　首先要先说SESSION是干什么的，SESSION是可以存储针对与某一个用户的IE以及通过其当
　　前窗口打开的任何窗口具有针对性的用户信息存储机制。为什么要这样说。看下边
　　先研究SESSION是如何启动的，当打开IE以后浏览网站后会发出一个指令请求SESSIONID以
　　及对各个类型数据的下载许可，如图片，声音以及FLASH。 
　　数据实际传输内容：IE到服务器 
　　GET / HTTP/1.1 
　　Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */* 
　　Accept-Language0: zh-cn 
　　Accept-Encoding: gzip, deflate 
　　User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 
　　Host: www.jh521.com
　　Connection: Keep-Alive 
　　服务器会返回一个没有被使用的SESSIONID让IE使用，当时IE就对返回SESSIONID做存储
　　并同时返回相关页面的下载数据，如下:服务器到IE 
　　HTTP/1.1 200 OK 
　　Server: Microsoft-IIS/5.0 
　　Date: Sun, 30 Nov 2003 16:41:51 GMT 
　　Content-Length: 21174..Content-Type: text/html 
　　Set-Cookie: ASPSESSIONIDCACBBBRT=IBOMFONAOJFEEBHBPIENJFFC; path=/ 
　　Cache-control: private 
　　然后就是页面HTML代码
　　此时这个IE程序(不是客户机)的SESSIONID就为IBOMFONAOJFEEBHBPIENJFFC
　　而当IE在访问任何这个站点的ASP程序的时候，就会把IBOMFONAOJFEEBHBPIENJFFC发送
　　给服务器，服务器就会知道IBOMFONAOJFEEBHBPIENJFFC是表示你 
　　而在服务器上设置SESSION("name")="name" 
　　完全可以看成是 
　　SESSION("IBOMFONAOJFEEBHBPIENJFFC")("name")="name" 
　　或者 
　　SESSION(SESSIONID)("name")="name" 
　　这样，SESSION就区分开用户了。 
　　而当服务器反馈这个ID的时候会看这个ID有没有被使用。如果有在换一个 
　　反正不会让你重复，如果想模拟某人的SESSION的ID来进行欺骗是可以的。不过要获取到
　　对方IE传输信号，并且在保证当时这个SESSIONID没有被取消的情况下才可能实施。
　　不过要是我有那时间直接通过POST信号找他NAME和PASS了。我可不费这个劲
　　想必一些人明白了了SESSIONID到底是如何工作的
　　那么就在看看COOKIE,有人说SESSIONID就是COOKIE，按照技术上来讲他们不属于同类
　　但是属于一种工作模式，用户和服务器传输私有数据
　　当我设置COOKIE的时候，服务器会反馈给IE一个指令。IE通过这个网络指令生成COOKIE并
　　存放,在特定的时候会取得这个这个信息如在访问这个站点并且COOKID有效的时候。
　　那么为什么要用COOKIE而不用SESSION呢 
　　看下区别
　　有效时间以及存储方式 传输内容 
　　COOKIE 可设置并在本地保留 明码信息
　　SESSION 在IE不关闭并服务器不超时 只有SESSIONID
　　当如果想让用户下次登入网站不需要输入用户名或者密码的时候就只能用COOKIE,
　　因为他可以保留相当长的时间(在COOKIE记录被删除或者失效日期之前)
　　而SESSION就不可以，他不会保留太长时间，而且IE在关闭后就自动清除了SESSIONID记录
　　在下次登入的时候会请求新的SESSIONID
　　而服务器想通过用户个人变量校验用户的状态的时候，就不能用COOKIE
　　如果用设置用户权限是USER。而IE访问的时候就把USER的明码传输到服务器。
　　那么如果我通过一定手段，比如直接修改COOKIE记录，把USER修改成ADMIN呢~~
　　就麻烦了。
　　但存储用户名和密码或者网站的配色方案这样的信息，用COOKIE是最好的
　　好，有点累了，在说说这个东西 
　　Request.ServerVariables("HTTP_REFERER")
　　我想有一些人通过这个Request.ServerVariables("HTTP_REFERER") 
　　来进行一些关键性限制,特别是对付远程提交以及非法侵入。 
　　那么我就要提醒下服务器取得的HTTP_REFERER信息完全是IE传输给服务器的，可以模拟 
　　而且难度不大，用不到半个小时就可以用VB做出一个针对HTTP_REFERER入侵程序。
　　================================================== =================
　　session有两种实现方式，其中用的最多的一种就是用cookie来实现的 
　　如果在这种情况下，你把cookie给禁了，那么session也就不能用了
　　至于哪两种实现方式
　　请看下面：
　　Session实现原理
　　http://blog.csdn.net/hql638/archive/2006/07/04/874 774.aspx
　　HTTP协议（http://www.w3.org/Protocols/）是"一次性单向"协议。 
　　服务端不能主动连接客户端，只能被动等待并答复客户端请求。客户端连接服务端，发出一个HTTP Request，服务端处理请求，并且返回一个HTTP Response给客户端，本次HTTP Request-Response Cycle结束。 
　　我们看到，HTTP协议本身并不能支持服务端保存客户端的状态信息。于是，Web Server中引入了session的概念，用来保存客户端的状态信息。 
　　这里用一个形象的比喻来解释session的工作方式。假设Web Server是一个商场的存包处，HTTP Request是一个顾客，第一次来到存包处，管理员把顾客的物品存放在某一个柜子里面（这个柜子就相当于Session），然后把一个号码牌交给这个顾客，作为取包凭证（这个号码牌就是Session ID）。顾客（HTTP Request）下一次来的时候，就要把号码牌（Session ID）交给存包处（Web Server）的管理员。管理员根据号码牌（Session ID）找到相应的柜子（Session），根据顾客（HTTP Request）的请求，Web Server可以取出、更换、添加柜子（Session）中的物品，Web Server也可以让顾客（HTTP Request）的号码牌和号码牌对应的柜子（Session）失效。顾客（HTTP Request）的忘性很大，管理员在顾客回去的时候（HTTP Response）都要重新提醒顾客记住自己的号码牌（Session ID）。这样，顾客（HTTP Request）下次来的时候，就又带着号码牌回来了。 我们可以看到，Session ID实际上是在客户端和服务端之间通过HTTP Request和HTTP Response传来传去的。 
　　我们看到，号码牌（Session ID）必须包含在HTTP Request里面。关于HTTP Request的具体格式，请参见HTTP协议（http://www.w3.org/Protocols/）。这里只做一个简单的介绍。 
　　在Java Web Server（即Servlet/JSP Server）中，Session ID用jsessionid表示（请参见Servlet规范）。 
　　HTTP Request一般由3部分组成： 
　　（1）Request Line 
　　这一行由HTTP Method（如GET或POST）、URL、和HTTP版本号组成。 
　　例如，GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 
　　GET http://www.google.com/search?q=Tomcat HTTP/1.1 
　　POST http://www.google.com/search HTTP/1.1 
　　GET http://www.somsite.com/menu.do;jsessionid=1001 HTTP/1.1 
　　（2）Request Headers 
　　这部分定义了一些重要的头部信息，如，浏览器的种类，语言，类型。Request Headers中还可以包括Cookie的定义。例如： 
　　User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) 
　　Accept-Language: en-us 
　　Cookie: jsessionid=1001 
　　（3）Message Body 
　　如果HTTP Method是GET，那么Message Body为空。 
　　如果HTTP Method是POST，说明这个HTTP Request是submit一个HTML Form的结果， 
　　那么Message Body为HTML Form里面定义的Input属性。例如， 
　　user=guest 
　　password=guest 
　　jsessionid=1001 
　　主意，如果把HTML Form元素的Method属性改为GET。那么，Message Body为空，所有的Input属性都会加在URL的后面。你在浏览器的URL地址栏中会看到这些属性，类似于 
　　http://www.somesite/login.do?use ... amp;jsessionid=1001
　　从理论上来说，这3个部分（Request URL，Cookie Header, Message Body）都可以用来存放Session ID。由于Message Body方法必须需要一个包含Session ID的HTML Form，所以这种方法不通用。 
　　一般用来实现Session的方法有两种： 
　　（1）URL重写。 
　　Web Server在返回Response的时候，检查页面中所有的URL，包括所有的连接，和HTML Form的Action属性，在这些URL后面加上";jsessionid=XXX"。 
　　下一次，用户访问这个页面中的URL。jsessionid就会传回到Web Server。 
　　（2）Cookie。 
　　如果客户端支持Cookie，Web Server在返回Response的时候，在Response的Header部分，加入一个"set-cookie: jsessionid=XXXX"header属性，把jsessionid放在Cookie里传到客户端。 
　　客户端会把Cookie存放在本地文件里，下一次访问Web Server的时候，再把Cookie的信息放到HTTP Request的"Cookie"header属性里面，这样jsessionid就随着HTTP Request返回给Web Server。 
　　我们来看Tomcat5的源代码如何支持jsessionid。 
　　org.apache.coyote.tomcat5.CoyoteResponse类的toEncoded()方法支持URL重写。 
　　String toEncoded(String url, String sessionId) { 
　　… 
　　StringBuffer sb = new StringBuffer(path); 
　　if( sb.length() > 0 ) { // jsessionid can't be first. 
　　sb.append(";jsessionid="); 
　　sb.append(sessionId); 
　　} 
　　sb.append(anchor); 
　　sb.append(query); 
　　return (sb.toString()); 
　　} 
　　我们来看org.apache.coyote.tomcat5.CoyoteRequest的两个方法configureSessionCookie() 
　　doGetSession()用Cookie支持jsessionid. 
　　/** 
　　* Configures the given JSESSIONID cookie. 
　　* 
　　* @param cookie The JSESSIONID cookie to be configured 
　　*/ 
　　protected void configureSessionCookie(Cookie cookie) { 
　　… 
　　} 
　　HttpSession doGetSession(boolean create){ 
　　… 
　　// Creating a new session cookie based on that session 
　　if ((session != null) && (getContext() != null) 
　　&& getContext().getCookies()) { 
　　Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME, 
　　session.getId()); 
　　configureSessionCookie(cookie); 
　　((HttpServletResponse) response).addCookie(cookie); 
　　} 
　　… 
　　} 
　　Session的典型应用是存放用户的Login信息，如用户名，密码，权限角色等信息，应用程序（如Email服务、网上银行等系统）根据这些信息进行身份验证和权限验证