在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运行环境。
分享到:
相关推荐
maven-glassfish-plugin-3.0-prelude.jar
maven-glassfish-extension-3.0-prelude.jar
maven-embedded-glassfish-plugin-3.0.jar
maven-glassfish-plugin-3.0-prelude-sources.jar
maven-glassfish-extension-3.0-prelude-sources.jar
maven-embedded-glassfish-plugin-3.0-sources.jar
maven-glassfish-plugin-3.0-prelude-embedded-m2.jar
maven-glassfish-extension-3.0-prelude-embedded-m2.jar
maven-glassfish-plugin-3.0-prelude-embedded-m2-sources.jar
maven-glassfish-extension-3.0-prelude-embedded-m2-sources.jar
NULL 博文链接:https://looseep.iteye.com/blog/1733874
GlassFish 中的数据源连接池是指在服务器中创建一个池子的概念,它允许应用程序从池子中获取数据库连接,以提高应用程序的性能和可扩展性。在 GlassFish 中,数据源连接池是通过 JDBC(Java Database Connectivity...
标签:container、glassfish、core、jersey、servlet、containers、jar包、java、中文文档; 使用方法:解压翻译后的API文档,用浏览器打开“index.html”文件,即可纵览文档内容。 人性化翻译,文档
### JMX 在GlassFish中的应用 #### JMX与GlassFish:深入理解管理与监控 **JMX(Java Management Extensions)**是一种由Sun Microsystems提出并由Java社区推动的标准,旨在为Java应用程序、系统和网络提供一个...
在测试过程中,可能会遇到一些问题,比如连接超时、消息传递延迟或者是服务器资源管理的问题。这些问题通常需要调试Grizzly的配置,调整连接池大小,或者优化Comet处理的代码来解决。同时,理解HTTP长连接的工作原理...
使用的客户端库: 服务器端在具有WebSocket支持的Tomcat,Jetty,WildFly,Glassfish和其他Servlet 3.0+容器上运行。Tomcat对于Tomcat,将TOMCAT_HOME设置为环境变量,并在此目录中使用和 。 打开浏览器,然后转到...