在Glassfish中测试servlet 3.0的SessionCookieConfig

最新推荐文章于 2022-01-21 12:09:12 发布

清风一池水

最新推荐文章于 2022-01-21 12:09:12 发布

阅读量3.3k

点赞数

分类专栏： J2EE 文章标签： servlet glassfish 测试浏览器 server path

本文链接：https://blog.csdn.net/wangjian5748/article/details/5076499

版权

J2EE 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

在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这个cookie到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运行环境。