java中的Cookie 和 Session

来源：互联网发布：ps cs6色环插件 mac 编辑：程序博客网时间：2024/05/17 06:02

最近实现网页访问量及在线人数的统计，看到一篇好文章。转之...

引用部分：

当浏览器得到这个 sessionid会将它放在自己的进程内存里,这里不同的浏览器会有所不同,IE进程间不能共享这个sessionid,也就是新开一个IE将不能共享这个sessionid;而Firefox进程间可以共享.然后你继续发请求给这个网站的时候,浏览器就会把这个sessionid放在请求头里发送给该服务器了,这样服务器得到sessionid后再和自己内存里存放的sessionid对比锁定客户端,从而区分不同客户端,完成会话.
   可以看出如果用这种方式,当用户在会话的过程中关闭浏览器结束进程,则这个sessionid将消失,如果用户又打开浏览器想继续这次会话的时候,就会因为发送的请求中没有这个sessionid而使服务器无法辨别该把那个session信息给他,注意(这个时候服务器端的sessionid和 sessionid所指向的session都还存在,只是没有正确的sessionid和它匹配而占用服务器内存,只有session过期或服务器重启才释放内存).
   上面这种方式叫会话cookie,把cookie放在浏览器内存里,只能在这个浏览器的内存范围里完成会话,是一种不长久的方式,为了能长久会话,就出现了持久化cookie,把cookie固化在用户的计算机上,现在的cookie不单单能存放sessionid,还能放用户信息,样式表信息等.
   如果用户禁止了所有cookie的使用,那么会话cookie和持久化cookie都不能用了,有个方案也可以解决问题,就是URL重写,这里要说下的就是URL重写只能实现会话cookie的效果,持久会话实现不了.

刚开始理解时，我也认为会有持久和会话这两种COOKIE。我认为，
会话COOKIE就是用来存放SESSIONID的，并且只存在于浏览器内存，浏览器关闭后会话COOKIE就被删除；
持久COOKIE就是用来存放其它信息，并且是在我们的本地硬盘里能看到的那种COOKIE。

然后我写了个SERVLET试了一下。

Java代码

public void service(HttpServletRequest request, HttpServletResponse response) throws IOException {
Cookie cookie = null;
PrintWriter out = response.getWriter();
out.println("<html><body>");
Cookie[] cookies = request.getCookies();
// 如果没有COOKIE，新建一个COOKIE
if (cookies == null) {
out.println("cookies is null.");
cookie = new Cookie("new", "1");
response.addCookie(cookie);
} else {
out.println("cookies is not null.");
for (int i = 0; i < cookies.length; i++) {
cookie = cookies[i];
out.println("cookie" + i + " name: " + cookie.getName() + "");
}
}
HttpSession session = request.getSession();
if (session == null) {
out.println("session is null.");
} else {
out.println("session is not null.");
out.println("session id: " + session.getId() + "");
}
out.println("</body></html>");
}

第一次访问这个SERVLET，页面显示

引用

cookies is null.
session is not null.
session id: 0D0AABB6F911362FEE87BEEB2953C33F

第二次访问，页面显示

引用

cookies is not null.
cookie0 name: new
cookie1 name: JSESSIONID
session is not null.
session id: 0D0AABB6F911362FEE87BEEB2953C33F

第二次访问时从客户端来了两个COOKIE，名为“new”的COOKIE是我创建的，名为“JSESSIONID”的COOKIE应该是服务器TOMCAT创建的，但这时，在本地硬盘里找不到这两个COOKIE的文件。

改一下SERVLET，在创建名为“new”的COOKIE时，加一句

Java代码

cookie.setMaxAge(1000);

然后本地硬盘里就有“new”这个COOKIE了。

这下就有疑问了，在没有设置COOKIE存活期时，自己创建的SESSION不会存到本地硬盘，会不会TOMCAT创建的所谓的会话COOKIE也是没有设置存活期呢？

然后根据zddava的博客（http://zddava.javaeye.com/blog/311053），找到了TOMCAT里创建会话COOKIE的代码。
在
org.apache.catalina.connector.Request.java里，

Java代码

protected void configureSessionCookie(Cookie cookie) {
cookie.setMaxAge(-1);
String contextPath = null;
if (!connector.getEmptySessionPath() && (getContext() != null)) {
contextPath = getContext().getEncodedPath();
}
if ((contextPath != null) && (contextPath.length() > 0)) {
cookie.setPath(contextPath);
} else {
cookie.setPath("/");
}
if (isSecure()) {
cookie.setSecure(true);
}
}

cookie.setMaxAge(-1);使COOKIE在浏览器被关闭时删除。而且这里的cookie和上面SERVLET里的cookie都是javax.servlet.http.Cookie。

由此得出结论，可能最开始是我理解错了，COOKIE并没有会话COOKIE和持久COOKIE之分。我们本地创建的“持久COOKIE”和 WEB容器创建的“会话COOKIE”都是一种COOKIE，就是javax.servlet.http.Cookie。只是WEB容器把存活期设置成了关闭浏览器时删除而已（TOMCAT）。

首先谈一下session对象在web开发中的创建以及sessionId生成并返回客户端的运行机制。

session对象当客户端首次访问时，创建一个新的session对象。并同时生成一个sessionId，并在此次响应中将sessionId 以响应报文的方式返回客户端浏览器内存或以重写url方式送回客户端，来保持整个会话，只要sever端的这个session对象没有销毁，以后再调用 request.getSession()时就直接根据客户端的sessionId来检索server端生成的session对象并返回，不会再次去新建，除非根据此sessionId没有检索到session对象。

下面是在IE下测试，因为IE 6.0的一个BUG就是IE的隐私设置。即使是阻止所有cookie时，也还是会以会话cookie来保存sessionId。所以下面都是以会话cookie来讨论的。

(1)在server没有关闭，并在session对象销毁时间内，当客户端再次来请求server端的servlet或jsp时，将会将在第一次请求时生成的sessionId并附带在请求信息头中并向server端发送，server端收到sessionId后根据此sessionId会去搜索 (此过程是透明的)server对应的session对象并直接返回这个session对象，此时不会重新去建立一个新的session对象。

(2)当server关闭(之前产生的session对象也就消亡了)，或session对象过了其销毁时间后，浏览器窗口不关，并在本浏览器窗口再次去请求sever端的servlet和jsp时，此时同样会将sessionId(server关闭或session销毁时生成的 sessionId)发送到server端，server根据sessionId去找其对应的session对象，但此时session对象已经不存在，此时会重新生成一个新的session对象，并生成新的sessionId并同样将这个新生成的sessionId以响应报文的形式送到浏览器内存中。

(3)当server没有关闭，并session对象在其销毁时间内，当请求一个jsp页面回客户端后，关闭此浏览器窗口，此时其内存中的 sessionId也就随之销毁，在重新去请求sever端的servlet或jsp时，会重新生成一个sessionId给客户端浏览器，并存在浏览内存中。

上面的理论在servlet中测试都是成立的，下面谈一下在struts框架下进行上面的测试时的不同的地方。

先简要说下测试程序的流程：

客户端请求index.do--->进入server端的IndexAction--->转向login.jsp页面----->请求login.do----->进入server端的LoginAction。

首先说明：IndexAction中没有去产生session对象，login.jsp中设置。

(1)环境servlet+jsp

在sevlet+jsp测试跟踪时，在index.do进入IndexAction后转向login.jsp时，此时浏览器内存中是没有会话 cookie的，那么在login.jsp上请求login.do进入LoginAction后，用request.getCookies()测试时，其值是为null的!结果是吻合的，因为从始至终没有产生过session。

(2)环境struts+jsp

在struts+jsp测试跟踪时，跟上面的流程一样，开始想结果也应该是一样的，但经过调试后发现结果却不是所想的那样。在login.do进入 LoginActoin后用，用request.getCookies()测试时，发现其值不为null，即使有name和value，开始很不理解，因为根本就没有创建过session对象，哪来的会话cookie值呢！但是结果有，那么想着此时浏览器内存中也就应该有会话cookie，问题就在这里! 从哪里来的?

后来经过仔细考虑后，想到struts中的特点，我们自己写的Action类是继承struts的Action的，而且之前是经过struts的中央控制器ActionServlet来控制转向的，所以我想肯定是在程序进入我自己写的IndexAction之前，struts框架中的代码肯定已经创建了session对象并已经生成了sessionId。于是就找到相关书籍查看了ActionServlet工作流程以及调用哪些类，看了之后果然在其中看到了HttpSession session = request.getSession();这样一句话!于是答案也就明白了。

大家知道struts的ActionServlet类中在接收到我们客户端的请求(*.do)后(之前会做一系列初始化工作)，并不是直接去处理我们的请求并调用相应的Action(我们写的如IndexAction)，而是将处理工作交给RequestProcessor类，其process方法中会调用一系列的方法来完成相应的请求处理和转向操作。其中有一个方法引起了我的关注，就是processLocale()方法。

Struts框架:RequestProcess类中的processLocale()方法，原型如下：

Java代码 java中的Cookie 和 Session - 程序人生 - 木头人

protected void processLocale(HttpServletRequest request,
HttpServletResponse response) {
// Are we configured to select the Locale automatically?
if (!moduleConfig.getControllerConfig().getLocale())
// Has a Locale already been selected?
HttpSession session = request.getSession();
if (session.getAttribute(Globals.LOCALE_KEY) != null)
// Use the Locale returned by the servlet container (if any)
Locale locale = request.getLocale();
if (locale != null) {
if (log.isDebugEnabled()) {
log.debug(" Setting user locale '" + locale + "'");
}
session.setAttribute(Globals.LOCALE_KEY, locale);
}
}

protected void processLocale(HttpServletRequest request, HttpServletResponse response) { // Are we configured to select the Locale automatically? if (!moduleConfig.getControllerConfig().getLocale()) // Has a Locale already been selected? HttpSession session = request.getSession(); if (session.getAttribute(Globals.LOCALE_KEY) != null) // Use the Locale returned by the servlet container (if any) Locale locale = request.getLocale(); if (locale != null) { if (log.isDebugEnabled()) { log.debug(" Setting user locale '" + locale + "'"); } session.setAttribute(Globals.LOCALE_KEY, locale); }}

此类在struts-config.xml配置文件中有对应的配置项：< controller locale="true">< /controller>其缺省状态locale属性的值为true，也就会调用processLocale方法，并在第一次请求时创建 session对象和生成sessionId。但改为false后，在第一次请求到达ActionServlet后不会调用processLocale方法，也就不会生成session对象了。

结果也就出来了，在struts应用中，*.do到达server端后经过ActionServlet后转想我们自己写的IndexAction之前，< controller locale="true">< /controller>(缺省状态)时，就已经产生了session对象和sessionId，这是struts框架类中生成的，即使我们在 IndexAction中写上HttpSession session = request.getSession();其也是RequestProcess类中的processLocale()方法生成的，此时其session 的isNew也还是true，因为还没有返回客户端，其是新创建的，那么按照上面的流程，当在login.jsp上通过login.do进入 LoginAction后，其request.getCookies()固然也就有值了!并且其值是RequestProcess类中的 processLocale()方法产生session对象时生成的。

如果我们在struts-config.xml中加上< controller locale="false">< /controller>时，此时如果再根据上面的流程来跟踪程序，并在LoginAction用request.getCookies()测试时，其值是为null的，当然在IndexAction写上HttpSession session = request.getSession();时其是进入IndexAction时新创建的，isNew也是true。