https://github.com/javahongxi
查看servlet-api.jar就可以知道Servlet规范大概包含哪些内容，下面翻译下规范中的“会话”，即HttpSession。
第7章 会话
超文本传输协议（HTTP）被设计为一种无状态协议。为构建有效的Web应用，必须把来自特定客户端的请求相互关联起来。随时间的推移，演变出了许多会话跟踪机制，但是程序员直接使用这些机制很困难或很麻烦。
该规范定义了一个简单的HttpSession接口，允许servlet容器使用任意几种方法来跟踪用户会话，而不会使应用开发人员陷入到这些方法的细微差别中。
7.1 会话跟踪机制
以下章节描述了跟踪用户会话（session）的方法。
7.1.1 Cookies
通过HTTP cookie的会话跟踪是最常用的会话跟踪机制，且所有servlet容器都应该支持。
容器向客户端发送一个cookie，客户端后续到服务器的请求都将返回该cookie，明确地将请求与会话关联。会话跟踪cookie的标准名字必须是JSESSIONID，所有3.0兼容的容器必须支持。容器可允许通过容器指定的配置自定义会话跟踪cookie的名字。
所有servlet容器必须提供能够配置容器是否标记会话跟踪cookie为HttpOnly。已建立的配置必须应用到所有还没有建立上下文特定配置的上下文中(见SessionCookieConfig javadoc获取更多细节)。
如果web应用为其会话跟踪cookie配置了一个自定义的名字，则如果会话id编码到URL中那么相同的自定义名字也将用于URI参数的名字（已开启URL重写）。
7.1.2 SSL会话
安全套接字层，HTTPS协议使用的加密技术，有一种内置机制允许来自客户端的多个请求被明确识别为同一会话。Servlet容器可以很容易地使用该数据来定义会话。
7.1.3 URL重写
URL重写是会话跟踪的最低标准。当客户端不接受cookie时，服务器可使用URL重写作为会话跟踪的基础。URL重写涉及添加数据、会话ID、容器解析URL路径从而把请求与会话相关联。
会话ID必须被编码为URL字符串中的一个路径参数。参数的名字必须是jsessionid。下面是一个URL包含编码的路径信息的例子：
http://www.myserver.com/catalog/index.html;jsessionid=1234
URL重写在日志、书签、referer头信息、缓存的HTML、URL工具条中暴露会话标识。在支持cookie或SSL 会话的情况下，不应该使用URL重写作为会话跟踪机制。
7.1.4 会话完整性
当服务来自客户端的HTTP请求不支持使用cookie时，Web容器必须能够支持HTTP 会话。 为了满足这个要求， Web容器通常支持URL重写机制。
7.2 创建会话
只有预期的会话和还没有建立的会话才被认为是“新”的会话。因为HTTP是一种基于请求-响应的协议，直到客户端“加入”到HTTP 会话之前它都被认为是新的。当会话跟踪信息返回到服务器指示会话已经建立时客户端才加入会话。客户端加入会话之前，不能假定下一个来自客户端的请求被确认为属于某个会话。
如果以下之一是true，会话被认为是“新”的：
■ 客户端还不知道会话
■ 客户端选择不加入会话。
这些条件定义了servlet容器没有把一个请求与之前的请求相关联的机制的情况。
Servlet开发人员必须设计他的应用以便处理客户端没有，不能，或不会加入会话的情况。
7.3 会话范围
HttpSession对象必须被限定在应用（或servlet上下文）级别。底层的机制，如建立会话使用的cookie，不同的上下文可以相同，但所引用的对象，包括该对象中的属性，决不能在容器上下文之间共享。
用一个例子来说明该要求： 如果servlet使用RequestDispatcher来调用另一个Web应用的servlet，任何创建的会话和被调用servlet所见的必须不同于调用会话所见的。
此外，一个上下文的会话必须可以通过请求进入上下文来恢复，而不管它们关联的上下文是直接访问，还是作为会话创建时的请求分派目标。
7.4 绑定Session属性
servlet可以按名称绑定对象属性到HttpSession实现，任何绑定到会话的对象可被属于同一个ServletContext的任何其他Servlet使用，并处理被确定为属于同一个会话的请求。
一些对象可能需要在它们被放进会话或从会话中移除时得到通知。这些信息可以从实现HttpSessionBindingListener接口的对象中获取。这个接口定义了以下方法，用于标识一个对象被绑定到会话或从会话解除绑定。
■ valueBound
■ valueUnbound
valueBound方法必须在对象可通过HttpSession接口的getAttribute方法得到之前被调用。valueUnbound方法必须在对象不再能够通过HttpSession接口的getAttribute方法得到之后被调用。
7.5 会话超时
在HTTP协议中，当客户端不再处于活动状态时没有显示的终止信号。这意味着当客户端不再处于活跃状态时可以使用的唯一机制是超时时间。
Servlet容器定义了默认的会话超时时间，且可以通过HttpSession接口的getMaxInactiveInterval方法获取。开发人员可以使用HttpSession 接口的setMaxInactiveInterval 方法改变超时时间。这些方法的超时时间以秒为单位。根据定义，如果超时时间设置为0或更小的值，会话将永不过期。直到使用该会话所有Servlet退出service方法之前，会话的有效性将不起作用。一旦会话已失效，新的请求必须不能看到该会话。
7.6 最后访问时间
HttpSession接口的getLastAccessedTime方法允许servlet确定在当前请求之前会话的最后访问时间。当servlet容器第一次处理属于该会话的请求时就认为该会话被访问了。
7.7 重要的会话语义
7.7.1 多线程问题
在同一时间多个Servlet执行请求的线程可能都有到同一会话的活跃访问。容器必须确保，以一种线程安全的方式维护表示会话属性的内部数据结构。开发人员负责线程安全的访问属性对象本身。这样将防止并发访问HttpSession对象内的属性集合，消除了应用程序导致破坏集合的机会。
7.7.2 分布式环境
在一个标识为分布式的应用程序中，会话中的所有请求在同一时间必须仅被一个JVM处理。容器必须能够恰当地处理使用setAttribute或putValue方法放入HttpSession类实例的所有对象。强制添加下面的限制来满足这些条件：
■ 容器必须接受实现了Serializable 接口的对象。
■ 容器可以选择支持把其他指定对象存储到HttpSession中，如Enterprise JavaBeans组件和事务的引用。
■ 由特定于容器的设施处理会话迁移。
当容器不支持迁移会话存储对象所必需的机制时分布式servlet容器必须抛出IllegalArgumentException。
分布式servlet容器必须支持迁移实现Serializable的对象所必需的机制。
这些限制意味着开发人员确保除在非分布式容器中遇到的问题以外没有额外的并发问题。
容器供应商可以确保可扩展性和服务质量的特性，如负载平衡和故障转移，通过把会话对象和它的内容从分布式系统的任意一个活跃节点移动到系统的另一个不同的节点上。
如果分布式容器持久化或迁移会话提供服务质量特性，它们不限制使用原生的JVM序列化机制来序列化HttpSession和它们的属性。如果开发人员实现session属性上的readObject 和 writeObject 方法，他们也不能保证容器将调用这些方法，但保证Serializable结束它们的属性将被保存。
容器必须在迁移会话时通知实现了HttpSessionActivationListener的所有会话属性。它们必须在序列化会话之前通知钝化监听器，在反序列化之后通知激活监听器。
写分布式应用的开发人员应该意识到容器可能运行在多个Java虚拟机中，开发人员不能依赖静态变量存储应用状态。他们应该用企业Bean或数据库存储这种状态。
7.7.3 客户端语义
由于Cookie或SSL证书通常由Web浏览器进程控制，且不与浏览器的任意特定窗口关联，从客户端应用程序发起的到servlet容器的请求可能属于同一会话。为了获得最大的可移植性，开发人员应该假定客户端所有窗口共享同一会话。