http中的cookie和session

转载自：https://blog.csdn.net/sinat_31057219/article/details/77849711

以及https://blog.csdn.net/canot/article/details/50667793 （略有删减）

*************************************************************************************************************************************************

一、Cookie和Session的区别和联系

参考：比特博文 | 5分钟搞懂cookie和session的区别

举个例子：

在学校旁边的一家面馆，有消费三碗免费一碗的活动。然而一次性消费三碗的可能性很小，需要用某种方式来记录顾客的消费状态，这时就有两种方案：

cookie方案: 发给顾客一张卡（cooike），上面记录着消费量，一般还有个时限。每次消费的时候顾客只要出示这张卡，则此次消费的状态就被记录下来了。这就是在客户端保持状态。

session方案: 同样发给顾客一张卡（cooike），但是卡上只有一个卡号（session id），用来标识用户身份，其他什么都没有。每次顾客去消费时，只要出示这张卡，则店员就在店里的记录本（session）上找到卡号所对应的记录，并且添加一些消费信息。这就是在服务器端保存状态的方法。

由于session方案需要session id(卡号)将客户端和服务器端连接起来，所以一般session机制需要借助cookie来在客户端保存session id。当然除了cookie还有一种url重写的方法也能够实现session机制。

为什么有了cookie还要用session

使用 cookie 有两个的弊端：
1、cookie 中的所有数据在客户端就可以被修改。这就意味着数据非常容易被伪造，一些重要的数据就不能存放在 cookie 中
2、如果 cookie 中数据字段太多会影响传输效率。

为了解决这些问题，就产生了 session，那么 session 又是怎样工作的呢？

每个 session 都对应一个 session_id，通过 session_id 可以查询到对应的 session，session_id 通常是存放在客户端的 cookie 中，服务端存好 session 之后将对应的 session_id 设置在 cookie 中发送给客户端。当请求到来时，服务端检查 cookie 中保存的 session_id 并通过这个 session_id 与服务器端的 session 关联起来，进行数据的保存和修改。

这意思就是说，当你浏览一个网页时，服务端随机产生一个很长的字符串，然后存在你 cookie 中。当你下次访问时，cookie 会带有这个字符串，然后浏览器就知道你是上次访问过的某某某，然后从服务器的存储中取出上次记录在你身上的数据。由于字符串是随机产生的，而且位数足够多，所以也不担心有人能够伪造。

cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。两者存储的都是用户登录信息，操作行为等等的数据。一般情况，登录信息等重要信息存储在session中，其他信息存储在cookie中。

区别：

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。
常用的会话跟踪技术是Cookie与Session。
Cookie通过在客户端记录信息确定用户身份，
Session通过在服务器端记录信息确定用户身份。

1，session 在服务器端，cookie 在客户端（浏览器）
2，session 默认被存在在服务器的一个文件里（不是内存）
3，session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）
4，session 可以放在文件、数据库、或内存中都可以。
5，用户验证这种场合一般会用 session 因此，维持一个会话的核心就是客户端的唯一标识，即 session id

Cookie是客户端请求服务端时服务器会将一些信息以键值对的形式返回给客户端，保存在浏览器中，交互的时候可以加上这些Cookie值。用Cookie就可以方便的做一些缓存。Cookie的缺点是大小和数量都有限制；Cookie是存在客户端的可能被禁用、删除、篡改，是不安全的；Cookie如果很大，每次要请求都要带上，这样就影响了传输效率。

Cookie可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

如果你把Cookies看成为http协议的一个扩展的话，理解起来就容易的多了，其实本质上cookies就是http的一个扩展。有两个http头部是专门负责设置以及发送cookie的,它们分别是Set-Cookie以及Cookie。当服务器返回给客户端一个http响应信息时，其中如果包含Set-Cookie这个头部时，意思就是指示客户端建立一个cookie，并且在后续的http请求中自动发送这个cookie到服务器端，直到这个cookie过期。如果cookie的生存时间是整个会话期间的话，那么浏览器会将cookie保存在内存中，浏览器关闭时就会自动清除这个cookie。另外一种情况就是保存在客户端的硬盘中，浏览器关闭的话，该cookie也不会被清除，下次打开浏览器访问对应网站时，这个cookie就会自动再次发送到服务器端。
　　
参考：Cookie 和 Session 的使用简记

二、cooike

cooike特点：

Cookie 就是浏览器储存在用户电脑上的一小段文本文件
Cookie 是纯文本格式，不包含任何可执行的代码
Cookie 由键值对构成，由分号和空格隔开
Cookie 虽然是存储在浏览器，但是通常由服务器端进行设置
Cookie 的大小限制在 4kb 左右,单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

cooike属性：

每个 Cookie 都有一定的属性，如什么时候失效，要发送到哪个域名，哪个路径等等。在设置任一个 Cookie 时都可以设置相关的这些属性，当然也可以不设置，这时会使用这些属性的默认值。

String name：该Cookie的名称。
Cookie一旦创建，名称便不可更改。

Object value：该Cookie的值。
如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码。

int maxAge：该Cookie失效的时间，单位秒。
如果为正数，则该Cookie在maxAge秒之后失效。
如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。
如果为0，表示删除该Cookie。默认为–1。

boolean secure：该Cookie是否仅被使用安全协议传输。安全协议。
安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。
指定cookie的值如何通过网络在用户和web服务器之间传递。
缺省情况下，这个属性为空，默认使用http传递数据。
如果被标记为”secure”，则使用HTTPS传递数据。

String path：该Cookie的使用路径。
如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。
如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。

String domain：可以访问该Cookie的域名。
如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。
注意第一个字符必须为“.”。

String comment：该Cookie的用处说明。
浏览器显示Cookie信息的时候显示该说明。

int version：该Cookie使用的版本号。
0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范。

expires / max-age区别：

expires / max-age
expires / max-age 都是控制 Cookie 失效时刻的选项。如果没有设置这两个选项，则默认有效期为 session，即会话 Cookie。这种 Cookie 在浏览器关闭后就没有了。

expires
expires 选项用来设置 Cookie 什么时间内有效，expires 其实是 Cookie 失效日期。
expires 必须是 GMT 格式的时间（可以通过 new Date().toGMTString() 或者 new Date().toUTCString() 来获得）

max-age
expires 是 http/1.0 协议中的选项，在新的 http/1.1 协议中 expires 已经由 max-age 选项代替，两者的作用都是限制 Cookie 的有效时间。expires 的值是一个时间点 (Cookie 失效时刻 = expires)，而 max-age 的值是一个以秒为单位时间段 (Cookie 失效时刻 = 创建时刻 + max-age)

优先级

如果同时设置了 max-age 和 expires，以 max-age 的时间为准。

domain 和 path

name、domain 和 path 可以标识一个唯一的 Cookie。domain 和 path 两个选项共同决定了 Cookie 何时被浏览器自动添加到请求头部中发送出去。

如果没有设置这两个选项，则会使用默认值。domain 的默认值为设置该 Cookie
的网页所在的域名，path 默认值为设置该 Cookie 的网页所在的目录。

httpOnly

这个选项用来设置 Cookie 是否能通过 js 去访问。默认情况下，Cookie 不会带 httpOnly 选项(即为空)，客户端是可以通过 js 代码去访问（包括读取、修改、删除等）这个 Cookie 的。当 Cookie 带 httpOnly 选项时，客户端则无法通过 js 代码去访问（包括读取、修改、删除等）这个 Cookie。
客户端中无法设置 HttpOnly 选项。

明确一点：Cookie 可以由服务端设置，也可以由客户端设置。
一个 Set-Cookie 字段只能设置一个 Cookie，当你要想设置多个 Cookie，需要添加同样多的 Set-Cookie 字段
服务端可以设置 Cookie 的所有选项：expires、domain、path、secure、HttpOnly

Cookie 的 name、path 和 domain 是唯一标识一个 Cookie 的。我们只要将一个 Cookie 的 max-age 设置为 0，就可以删除一个 Cookie 了。

三、session

session 储存

session 的储存有四个常用选项：内存、 cookie、缓存、数据库

内存：开发环境存内存比较方便，问题是不能够共享状态（只能在本机访问）
cookie：使用 cookie 来储存 session 的话，session 保存在用户浏览器端，每次用户访问时，都会主动带上他自己的信息。安全性的话，只要遵照最佳实践来，也是有保证的。它的弊端是增大了数据量传输，好处是比较方便
缓存：可以共享
数据库：可以共享

signedCookie

如果非要使用 cookie 来记录登陆的用户凭证，也不是不可以，只需要做一些对 cookie 做一个哈希处理就好了。
这样一来，用户就没法伪造信息了。一旦它更改了 cookie 中的信息，则服务器会发现 hash 校验的不一致。
毕竟他不懂我们的 secret_string 是什么，而暴力破解哈希值的成本太高。

特点：

Session是基于Cookie来实现的，不同的是Session本身存在于服务端，但是每次传输的时候不会传输数据，只是把代表一个客户端的唯一ID（通常是JSESSIONID）写在客户端的Cookie中，这样每次传输这个ID就可以了。

Session的优势就是传输数据量小，比较安全。
但是Session也有缺点，就是如果Session不做特殊的处理容易失效、过期、丢失或者Session过多导致服务器内存溢出，并且要实现一个稳定可用安全的分布式Session框架也是有一定复杂度的。在实际使用中就要结合Cookie和Session的优缺点针对不同的问题来设计解决方案。

通讯过程：

第一次请求接口，我们看到 Request Headers 并没有 Cookie 这个字段
但是 Response Headers 有了 Set-Cookie 这个字段：

现在我们刷新一下页面，相当于重新向接口这个地址发起了一次请求。

现在我们就可以看到 Cookie 字段已经带上了，再刷新几次看 Cookie 也还是在的。

参考：Cookie 在前端中的实践
参考：Session是什么

session的实现原理

服务器会为每一个访问服务器的用户创建一个session对象，并且把session对象的id保存在本地cookie上，只要用户再次访问服务器时，带着session的id，服务器就会匹配用户在服务器上的session，根据session中的数据，还原用户上次的浏览状态或提供其他人性化服务。

浏览器禁用cookie后如何实现session

如果客户端浏览器将Cookie功能禁用，或者不支持Cookie怎么办？例如，绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案：URL地址重写。

URL地址重写

URL重写就是首先获得一个进入的URL请求然后把它重新写成网站可以处理的另一个URL的过程。举个例子来说，如果通过浏览器进来的URL是“UserProfile.aspx?ID=1”那么它可以被重写成 “UserProfile/1.aspx”，这样的URL，这样的网址可以更好的被网站所阅读。

如何通过URL地址重写实现session的id传输

URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(String url)实现URL地址重写，该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。

四、session和cookie的有效时长

session的有效时长

服务器会把长时间没有活动的Session从服务器内存中清除，此时Session便失效。具体根据服务器设置，一般在二三十分钟左右。

cookie的有效时长

cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。通过过期时间可以设置cookie的有效时长.
若不设置过期时间: 表示这个cookie的生命周期为浏览器回话期间，关闭访问服务器的浏览器窗口，cookie就消失了。一般称为回话cookie，保存在内存中
若设置了过期时间：则cookie会存储在硬盘上，直到超过有效时间。

*************************************************************************************************************************************************

实现会话跟踪最常见的技术就是使用Session或者Cookie。而关于Session或者Cookie即简单又复杂。简单是因为它们本身只是 HTTP 协议中的一个配置项，在 Servlet 规范中也只是对应到一个类而已；说它复杂原因在于当我们的系统大到需要用到很多 Cookie 的时候，我们不得不考虑 HTTP 协议对 Cookie 数量和大小的限制，那么如何才能解决这个瓶颈呢？ Session 也会有同样的问题，当我们的一个应用系统有几百台服务器的时候如何解决 Session 在多台服务器之间共享？…

Session 与 Cookie 的作用都是为了保持访问用户与后端服务器的交互状态。它们有各自的优点，也有各自的缺陷，然而具有讽刺意味的是它们的优点和它们的使用场景又是矛盾的。例如，使用 Cookie 来传递信息时，随着 Cookie 个数的增多和访问量的增加，它占用的网络带宽也很大，试想假如 Cookie 占用 200 个字节，如果一天的 PV 有几亿，它要占用多少带宽？所以有大访问量的时候希望用 Session，但是 Session 的致命弱点是不容易在多台服务器之间共享，所以这也限制了 Session 的使用。

HTTP Session篇

1、概念：

Session代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续的。在Servlet中，session指的是HttpSession类的对象，这个概念到此结束了，也许会很模糊，但只有看完本文，才能真正有个深刻理解。

下面是两次请求同一个jsp，第二次请求头信息：

这里写图片描述

在第一次请求时是不存在如上图的JSESSIONID的。第二次请求的时候，已经添加session ID的信息。

session存放在哪里：服务器端的内存中。不过session可以通过特殊的方式做持久化管理。

session的id是从哪里来的，sessionID是如何使用的：当客户端第一次请求session对象时候，服务器会为客户端创建一个 session，并将通过特殊算法算出一个session的ID，用来标识该session对象，当浏览器下次（session继续有效时）请求别的资源的时候，浏览器会偷偷地将sessionID放置到请求头中，服务器接收到请求后就得到该请求的sessionID，服务器找到该id的session返还给请求者（Servlet）使用。一个会话只能有一个session对象，对session来说是只认id不认人。

3.同一客户端机器多次请求同一个资源，session一样吗？

一般来说，每次请求都会新创建一个session。
但这个也不一定的，总结下：对于多标签的浏览器（比如360浏览器）来说，在一个浏览器窗口中，多个标签同时访问一个页面，session是一个。对于多个浏览器窗口之间，同时或者相隔很短时间访问一个页面，session是多个的，和浏览器的进程有关。对于一个同一个浏览器窗口，直接录入url访问同一应用的不同资源，session是一样的。
session因为请求（request对象）而产生，同一个会话中多个request共享了一session对象，可以直接从请求中获取到session对象。
其实，session的创建和使用总在服务端，而浏览器从来都没得到过session对象。但浏览器可以请求Servlet（jsp也是Servlet）来获取session的信息。客户端浏览器真正紧紧拿到的是session ID，而这个对于浏览器操作的人来说，是不可见的，并且用户也无需关心自己处于哪个会话过程中。

4.Session的生命周期

Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。
Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。
Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。
由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。
Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(longinterval)修改。
Session的超时时间也可以在web.xml中修改。另外，通过调用Session的invalidate()方法可以使Session失效。

这里写图片描述

5.Session对浏览器的要求

虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session 需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session 依据该Cookie来识别是否为同一用户。
该Cookie为服务器自动生成的，它的maxAge属性一般为–1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。
因此同一机器的两个浏览器窗口访问服务器时，会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。
注意：新开的浏览器窗口会生成新的Session，但子窗口除外。子窗口会共用父窗口的Session。例如，在链接上右击，在弹出的快捷菜单中选择“在新窗口中打开”时，子窗口便可以访问父窗口的Session。
如果客户端浏览器将Cookie功能禁用，或者不支持Cookie怎么办？例如，绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案：URL地址重写。

Cookie篇

Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。
Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。
即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。
Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

1.什么是Cookie

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
Java中把Cookie封装成了javax.servlet.http.Cookie类。每个Cookie都是该Cookie类的对象。服务器通过操作Cookie类对象对客户端Cookie进行操作。通过request.getCookie()获取客户端提交的所有Cookie（以Cookie[]数组形式返回），通过response.addCookie(Cookiecookie)向客户端设置Cookie。

2.Cookie 对象的内容

Cookie对象使用key-value属性对的形式保存用户状态，一个Cookie对象保存一个属性对，一个request或者response同时使用多个Cookie。因为Cookie类位于包javax.servlet.http.*下面，所以JSP中不需要import该类。

这里写图片描述

3.Cookie的不可跨域名性

很多网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Baidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢？或者Google能不能修改Baidu颁发的Cookie呢？
答案是否定的。Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。
Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作 Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名不一样，因此Google不能操作Baidu的Cookie。

中文与英文字符不同，中文属于Unicode字符，在内存中占4个字符，而英文属于ASCII字符，内存中只占2个字节。Cookie中使用Unicode字符时需要对Unicode字符进行编码，否则会乱码。
提示：Cookie中保存中文只能编码。一般使用UTF-8编码即可。不推荐使用GBK等中文编码，因为浏览器不一定支持，而且JavaScript也不支持GBK编码.

4.Cookie的有效期

Cookie的maxAge决定着Cookie的有效期，单位为秒（Second）。Cookie中通过getMaxAge()方法与setMaxAge(int maxAge)方法来读写maxAge属性。
如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效。浏览器会将maxAge为正数的 Cookie持久化，即写到对应的Cookie文件中。无论客户关闭了浏览器还是电脑，只要还在maxAge秒之前，登录网站时该Cookie仍然有效。下面代码中的Cookie信息将永远有效。

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie
cookie.setMaxAge(Integer.MAX_VALUE);           // 设置生命周期为MAX_VALUE
response.addCookie(cookie);                    // 输出到客户端

如果maxAge为负数，则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该Cookie即失效。maxAge为负数的 Cookie，为临时性Cookie，不会被持久化，不会被写到Cookie文件中。Cookie信息保存在浏览器内存中，因此关闭浏览器该Cookie 就消失了。Cookie默认的maxAge值为–1。
如果maxAge为0，则表示删除该Cookie。Cookie机制没有提供删除Cookie的方法，因此通过设置该Cookie即时失效实现删除Cookie的效果。失效的Cookie会被浏览器从Cookie文件或者内存中删除，
例如：

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie
cookie.setMaxAge(0);                          // 设置生命周期为0，不能为负数
response.addCookie(cookie);                    // 必须执行这一句
response对象提供的Cookie操作方法只有一个添加操作add(Cookie cookie)。

要想修改Cookie只能使用一个同名的Cookie来覆盖原来的Cookie，达到修改的目的。删除时只需要把maxAge修改为0即可。

注意：从客户端读取Cookie时，包括maxAge在内的其他属性都是不可读的，也不会被提交。浏览器提交Cookie时只会提交name与value属性。maxAge属性只被浏览器用来判断Cookie是否过期。

5.Cookie的修改、删除

Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。
如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。读者可以通过上例的程序进行验证，设置不同的属性。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

6.Cookie的域名

Cookie是不可跨域名的。域名www.google.com颁发的Cookie不会被提交到域名www.baidu.com去。这是由Cookie的隐私安全机制决定的。隐私安全机制能够禁止网站非法获取其他网站的Cookie。
正常情况下，同一个一级域名下的两个二级域名如www.helloweenvsfei.com和 images.helloweenvsfei.com也不能交互使用Cookie，因为二者的域名并不严格相同。如果想所有 helloweenvsfei.com名下的二级域名都可以使用该Cookie，需要设置Cookie的domain参数，例如：

Cookie cookie = new Cookie("time","20080808"); // 新建Cookie
cookie.setDomain(".helloweenvsfei.com");           // 设置域名
cookie.setPath("/");                              // 设置路径
cookie.setMaxAge(Integer.MAX_VALUE);               // 设置有效期
response.addCookie(cookie);                       // 输出到客户端

读者可以修改本机C:\WINDOWS\system32\drivers\etc下的hosts文件来配置多个临时域名，然后使用setCookie.jsp程序来设置跨域名Cookie验证domain属性。

注意：domain参数必须以点(“.”)开始。另外，name相同但domain不同的两个Cookie是两个不同的Cookie。如果想要两个域名完全不同的网站共有Cookie，可以生成两个Cookie，domain属性分别为两个域名，输出到客户端。
Cookie的路径。

domain属性决定运行访问Cookie的域名，而path属性决定允许访问Cookie的路径（ContextPath）。例如，如果只允许/sessionWeb/下的程序使用Cookie，可以这么写：

Cookie cookie = new Cookie("time","20080808");     // 新建Cookie
cookie.setPath("/session/");                          // 设置路径
response.addCookie(cookie);                           // 输出到客户端

设置为“/”时允许所有路径使用Cookie。path属性需要使用符号“/”结尾。name相同但domain相同的两个Cookie也是两个不同的Cookie。

注意：页面只能获取它属于的Path的Cookie。例如/session/test/a.jsp不能获取到路径为/session/abc/的Cookie。使用时一定要注意。

7.Cookie的安全属性

HTTP协议不仅是无状态的，而且是不安全的。使用HTTP协议的数据不经过任何加密就直接在网络上传播，有被截获的可能。使用HTTP协议传输很机密的内容是一种隐患。如果不希望Cookie在HTTP等非安全协议中传输，可以设置Cookie的secure属性为 true。浏览器只会在HTTPS和SSL等安全协议中传输此类Cookie。下面的代码设置secure属性为true：

Cookie cookie = new Cookie("time", "20080808"); // 新建Cookie
cookie.setSecure(true);                           // 设置安全属性
response.addCookie(cookie);                        // 输出到客户端

提示：secure属性并不能对Cookie内容加密，因而不能保证绝对的安全性。如果需要高安全性，需要在程序中对Cookie内容加密、解密，以防泄密。

8.JavaScript操作Cookie

Cookie是保存在浏览器端的，因此浏览器具有操作Cookie的先决条件。浏览器可以使用脚本程序如 JavaScript等操作Cookie。这里以JavaScript为例介绍常用的Cookie操作。例如下面的代码会输出本页面所有的Cookie。

<script>document.write(document.cookie);</script>

由于JavaScript能够任意地读写Cookie，有些好事者便想使用JavaScript程序去窥探用户在其他网站的Cookie。不过这是徒劳的，W3C组织早就意识到JavaScript对Cookie的读写所带来的安全隐患并加以防备了，W3C标准的浏览器会阻止JavaScript读写任何不属于自己网站的Cookie。换句话说，A网站的JavaScript程序读写B网站的Cookie不会有任何结果。

9.永久登录

如果用户是在自己家的电脑上上网，登录时就可以记住他的登录信息，下次访问时不需要再次登录，直接访问即可。实现方法是把登录信息如账号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登录信息即可。
保存登录信息有多种方案。最直接的是把用户名与密码都保持到Cookie中，下次访问时检查Cookie中的用户名与密码，与数据库比较。这是一种比较危险的选择，一般不把密码等重要信息保存到Cookie中。
还有一种方案是把密码加密后保存到Cookie中，下次访问时解密并与数据库比较。这种方案略微安全一些。如果不希望保存密码，还可以把登录的时间戳保存到Cookie与数据库中，到时只验证用户名与登录时间戳就可以了。
这几种方案验证账号时都要查询数据库。

URL地址重写

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。 HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写，例如：

<td>
    <a href="<%=response.encodeURL("index.jsp?c=1&wd=Java") %>"> 
    Homepage</a>
</td>

该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。重写后的输出可能是这样的：

<td>
    <a href="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=
    1&wd=Java">Homepage</a>
</td>

即在文件名的后面，在URL参数的前面添加了字符串“;jsessionid=XXX”。其中XXX为Session的 id。分析一下可以知道，增添的jsessionid字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户单击这个链接的时候会把 Session的id通过URL提交到服务器上，服务器通过解析URL地址获得Session的id。
如果是页面重定向（Redirection），URL地址重写可以这样写：

<%
    if(“administrator”.equals(userName))
    {
       response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”));
        return;
    }
%>

效果跟response.encodeURL(String url)是一样的：如果客户端支持Cookie，生成原URL地址，如果不支持Cookie，传回重写后的带有jsessionid字符串的地址。
对于WAP程序，由于大部分的手机浏览器都不支持Cookie，WAP程序都会采用URL地址重写来跟踪用户会话。比如用友集团的移动商街等。

注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。

Session中禁止使用Cookie

既然WAP上大部分的客户浏览器都不支持Cookie，索性禁止Session使用Cookie，统一使用URL地址重写会更好一些。Java Web规范支持通过配置的方式禁用Cookie。下面举例说一下怎样通过配置禁止使用Cookie。
打开项目sessionWeb的WebRoot目录下的META-INF文件夹（跟WEB-INF文件夹同级，如果没有则创建），打开context.xml（如果没有则创建），编辑内容如下：
代码1.11 /META-INF/context.xml

<?xml version='1.0' encoding='UTF-8'?>
<Context path="/sessionWeb"cookies="false">
</Context>

或者修改Tomcat全局的conf/context.xml，修改内容如下：
代码1.12 context.xml

<!-- The contents of this file will be loaded for eachweb application -->
<Context cookies="false">
    <!-- ... 中间代码略 -->
</Context>

部署后TOMCAT便不会自动生成名JSESSIONID的Cookie，Session也不会以Cookie为识别标志，而仅仅以重写后的URL地址为识别标志了。

注意：该配置只是禁止Session使用Cookie作为识别标志，并不能阻止其他的Cookie读写。也就是说服务器不会自动维护名为JSESSIONID的Cookie了，但是程序中仍然可以读写其他的Cookie。