`
izuoyan
  • 浏览: 9260452 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

在Glassfish中测试servlet 3.0的SessionCookieConfig

阅读更多

在servlet3.0以前,servlet规范是强制规定cookie名字为JSESSIONID,而Servlet3.0添加了一个新类:SessionCookieConfig,这个类是用来修改会话跟踪的cookie相关信息的,包括name,path,domain... (若浏览器用cookie的话,是这样,若不用cookie,则name是url重写的参数名)。为了测试这个新功能,我测试了sun公司提供的例子:sessioncookieconfig-war,这个示例是把默认的JSESSIONID改为MYJSESSIONID。在默认情况下,执行这个例子是成功的,也就是可以在netbeans中run这个例子成功。但是成功的标志是什么呢?显然我们我具体分析一下,我认为这个例子成功的标识应该是这样一个流程:

1.第一步浏览器访问,server用SessionCookieConfig修改JSESSIONID,打印出sessionId,server正确返回;这个例子的协议抓取的响应信息如下:

HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
Server: GlassFish v3
Set-Cookie: MYJSESSIONID=56eb237167919b3611150b227bbe; Version=1; Comment=myComment; Domain=mydomain; Max-Age=123; Expires=Wed, 13-Jan-2010 02:08:39 GMT; Path=/myPath; Secure; HttpOnly
Content-Length: 9
Date: Wed, 13 Jan 2010 02:06:36 GMT

SUCCESS

从上面的输出信息中,我们可以看到用SessionCookieConfig成功修改了cookie的属性。

2.第二步浏览器再访问,server第二次打印出sessionId,看两次是否一致,若一致,则可以认为这个实验部分成功(据我所知,目前所有的servlet引擎实现的sessionid的值域cookie的值总是相等的)。为什么是部分呢?因为我们还需要协议截取工具,抓取http协议,看cookie的名称是否是MYJSESSIONID,若这个也正确,则认为实验完全成功。当然这个要看对cookie的各个属性设置正确,比如domain,以及path,假如下一次访问的url不是cookie path的子目录,浏览器就不是提交这个cookie。

所以说sun公司的例子不是特别完整。在这个例子中,只有一次浏览器访问,只能通过debug看java代码执行修改SessionCookieConfig是否成功,以及使用http协议抓取工具,看cookie的名字。但是下一次浏览器是否会submit这个cokkie到server端呢?其实从上面响应信息已经可以看出问题了,MYJSESSIONID的有Secure值,这个值说明只有在HTTPS协议下,浏览器才会submit这个cookie,当然还有其它相关属性值(domain,path)。为了测试我的想法,我改造了这个例子。

第一步.在这个例子中,再添加一次请求,用http协议抓取工具看第二次的请求是否会带第一次返回的cookie

示例改造:注销掉CreateSession中检测cookie的代码(后面说明),在web目录下,添加一个test.jsp页面,内容随便,只要能请求就行。然后看第二次请求时浏览器是否会带MYJSESSIONID这个cookie。实验表明没有自动这个cookie

第二步,再修改ConfigListener类中的scc.setSecure(true)代码,改为scc.setSecure(false),实验结果还是不对

第三步,再注销scc.setPath("/myPath");,实验结果还是不对

第二步,再注销scc.setDomain("mydomain");,实验结果终于对了,也就是第二次的请求浏览器带了MYJSESSIONID这个cookie。

其实要是对cookie技术有所了解的朋友应该会理解上面的分析。比如,不注销scc.setPath()方法,改为scc.setPath(sce.getServletContext().getContextPath())。

现在回过头来再分析sun公司的例子,其实,在CreateSession类里也测试了Http协议的reponse的header属性Set-Cookie属性,其实这就是http协议头的一个属性,server告诉浏览器,需要设置这样一个cookie。我觉得,这种方式测试不能100%说明问题,这只是在server的代码。具体有没有反应到浏览器端,还是需要用一个http协议拦截工具来辅助测试想法,比如Fiddler,就很好用,只是需要安装.net运行环境。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics