超文本传输协议(HTTP)被设计为一个无状态协议。为构建高效的web应用程序,来自一个特殊客户端请求彼此之间互相关联非常必要。虽然回话跟踪的许多策略已经进化了很久,但是对于开发人员直接使用还是很困难。
这个规范定义了一个简单的HttpSession接口,允许servlet 容器使用一些方法来跟踪用户的会话,不需要开发者涉及到任何一个细微差别的方法。
7.1 Session Tracking Mechanisms (--会话跟踪机制)
下面章节描述了跟踪用户会话的方法
7.1.1 Cookie
HTTP Cookie的会话跟踪用的最多的会话跟踪机制并且所有的容器都支持。
容器发送客户端一个cookie。客户端将返回每个分布式请求的cookie给服务器,毫无疑问,一个会话与这个请求关联。会话跟踪cookie的标准名必须是JSESSIONID,必须被所有使用3.0的容器支持。通过容器特殊配置,容器可能允许定制会话跟踪cookie命名。
所有的servlet容器必须提供配置能力,不管容器是否以HttpOnly标记会话跟踪cookie。建立的配置必须适用于所有的上下文,针对一个上下文的特殊配置还没有建立。
如果一个web应用程序对于它的会话跟踪cookie配置了一个通用名,相同的通用名称也用于URI参数的名字,如果这个session id 在URL中进行了编码(改写URL)
7.1.2 SSL Sessions(SSL 会话)
安全套接字层,用于HTTP协议的加密技术,由一个构建机制,允许客户端的多个请求被正确识别为一个会话的部分。一个servlet容器可以很容易使用这个数据定义一个会话。
7.1.3 URL Rewriting (改写URL)
改写URL是会话跟踪的最小公分母。当一个客户端不接受一个cookie时,改写URL可能被服务器用作会话跟踪的主要部分。改写URL涉及到添加数据,一个会话ID,到URL路径,这个路径被容器解释为用一个会话关联这个请求。
这个会话id在URL字符串中作为一个路径参数必须要经过编码。参数名必须是jsessionid。下面是一个URL的例子,包含了加密路径信息。
http://www.myserver.com/catalog/index.html;jsessionid=1234
会话改写后的会话标示存在于日志,书签,相关的消息头,缓存的HTML,和URL中。URL改写不应该用作会话跟踪机制,其支持cookie或者SSL会话。
7.1.4 Session Integrity (会话的完整性)
在服务来自客户端的HTTP请求时,web 容器必须能够支持HTTP会话,这些客户端不支持会话的使用。为满足这种需求,Web容器一般支持URL改写机制。