java servlet3.1规范解读系列八：session 和cookies

会话

超文本传输协议（HTTP）被设计为一种无状态协议。为构建有效的 Web 应用，必须与来自一个特定的客 户端的请求彼此是相互关联。随时间的推移，演变了许多会话跟踪机制，这些机制直接使用对程序员而言 是困难或麻烦的。 该规范定义了一个简单的 HttpSession 接口，允许 servlet 容器使用几种方法来跟踪用户会话，而不会使应用 开发人员陷入到这些方法的细节中。

 

会话跟踪机制 以下章节描述了跟踪用户会话（session）的方法。

Cookies

通过 HTTP cookie 的会话跟踪是最常用的会话跟踪机制，且所有 servlet 容器都应该支持。 容器向客户端发送一个 cookie，客户端后续到服务器的请求都将返回该 cookie，明确地将请求与会话关联。 会话跟踪 cookie 的标准名字必须是 JSESSIONID，所有 3.0 兼容的容器必须支持。容器也允许通过容器指 定的配置自定义会话跟踪 cookie 的名字。 所有 servlet 容器必须提供能够配置容器是否标记会话跟踪 cookie 为 HttpOnly。已建立的配置必须应用到所 有上下文中还没有建立特定的配置(见 SessionCookieConfig javadoc 获取更多细节)。 如果 web 应用为其会话跟踪 cookie 配置了一个自定义的名字，则如果会话 id 编码到 URL 中那么相同的自 定义名字也将用于 URI 参数的名字（假如 URL 重写已开启）。

URL 重写 URL 重写是会话跟踪的最低标准。当客户端不接受 cookie 时，服务器可使用 URL 重写作为会话跟踪的基 础。URL 重写涉及添加数据、会话 ID、容器解析 URL 路径从而请求与会话相关联。 会话 ID 必须被编码为 URL 字符串中的一个路径参数。参数的名字必须是 jsessionid。下面是一个 URL 包 含编码的路径信息的例子： http://www.myserver.com/catalog/index.html;jsessionid=1234 URL 重写在日志、书签、referer header、缓存的 HTML、URL 工具条中暴露会话标识。在支持 cookie 或 SSL 会话的情况下，不应该使用 URL 重写作为会话跟踪机制。

 

规范中原文描述如上！

那么谈谈我自己的理解。

1： 对于session和cookies 我们知道都是一种保存信息的一种方式，session 为保存在服务端，cookies为保存在客户端，每次请求附带cookies在请求中发送服务端，这是对这两种信息保存的基本认知！

2： session的实现其实也是借助于cookies，是通过容器隐式的在cookies中写入了一条名称为：JSESSIONID 的数据

3： 当浏览器禁用cookies时，容器要可以进行url重写，重新中必须附带路径参数 jsessionid

4： http是一种无状态的文本传输协议。 这个一定要有清楚的认知，不管是cookies或者是session其实本身也是没有状态的，只是通过一个固定的标示来标志当前请求，是回话跟踪机制的实现！

 

扩展问题：

在分布式环境中，同一个浏览器的不同请求分布在不同的主机上，不同主机对客户端请求处理的JsessionId必定是不一样的，那么，在分布式环境中，session如何实现？

 

针对如上问题，环境访问：

https://blog.csdn.net/wangan_0601/article/details/90673401