Cookie如何工作以及使用限制。

Cookie的作用我想大家都知道，通俗的说就是当一个用户通过HTTP访问一个服务器时，这个服务器会将一些Key/Value键值对返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时这个用户下次访问这个服务器时，数据又被完整的带回给服务器。

如何工作

Cookie是如何加到HTTP的Header中的呢？当我们用Servlet 3.0 规范来创建一个Cookie对象时，该Cookie既支持Version 0 又支持Version 1，如果你设置了Version 1中的配置项，即使你没有设置版本号，Tomcat在最后构建HTTP响应头时也会自动将Version的版本设置为1.下面看一下Tomcat是如何调用addCookie方法的，下图是Tomcat创建Set-Cookie响应头的时序图。

从上图中可以看出，真正构建Cookie是在org.apache.catalina.connector.Response类中完成的，调用generateCookieString方法将Cookie对象构造成一个字符串，构造的字符串的格式如userName="xxx";Version="1";Domain="xxx.net";Max-Age=1000。然后将这个字符串命名为Set-Cookie添加到MimeHeaders中。

在这里有以下几点需要注意。

•     所创建Cookie的NAME不能和Set-Cookie或者Set-Cookie2的属性项值一样，如果一样会抛出IllegalArgumentException异常。
•     所创建Cookie的NAME和VALUE的值不能设置成非ASSIC字符，如果要使用中文，可以通过URLEncoder将其编码，否则会抛出IllegalArgumentException异常。
•     当NAME和VALUE的值出现一些TOKEN字符（如“\”、“,”）时，构建返回头会将该Cookie的Version自动设置为1。
•     当在该Cookie的属性项中出现Version为1的属性项时，构建HTTP响应头同样会将Version设置为1。

不知道你有没有注意到一个问题，就是当我们通过response.addCookie创建多个Cookie时，这些Cookie最终是在一个Header项中的还是以独立的Header存在的，通俗的说也就是我们每次创建Cookie时是否都是创建一个以NAME为Set-Cookie的MimeHeaders？答案是肯定的。从上面的时序图中可以看出每次调用addCookie时，最终都会创建一个Header，但是我们还不知道最终在请求返回构造的HTTP响应头是否将相同Header标识的Set-Cookie值进行合并。

我们找到Tomcat最终构造Htpp响应头的代码，这段代码位于org.apache.coyote.http11.Http11Processor类的prepareResponse方法中。
方法中，在构建HTTP返回字节流时是将Header中所有的项顺序的写出，而没有进行任何修改。所以可以想象浏览器在接收HTTP返回的数据时是分别解析每一个Header项的。

另外，目前很多工具都可以观察甚至可以修改浏览器中的Cookie数据。例如，在Firefox中可以通过HttpFox插件来查看返回的Cookie数据。

前面主要介绍了在服务端如何创建Cookie，下面看一下如何从客户端获取Cookie。

当我们请求某个URL路径时，浏览器会根据这个URL路径将符合条件的Cookie放在Request请求头中传回给服务端，服务端通过request.getCookies()来取得所有Cookie。

使用限制

Cookie是HTTP头中的一个字段，虽然HTTP本身对这个字段并没有多少限制，但是Cookie最终还是存储在浏览器里，所以不同的浏览器对Cookie的存储都有一些限制，下表是一些通常的浏览器对Cookie的大小和数量的限制。

浏览器版本	Cookie的数量限制	Cookie的总大小限制
IE6	20个/每个域名	4095个字节
IE7	50个/每个域名	4095个字节
IE8	50个/每个域名	4095个字节
IE9	50个/每个域名	4095个字节
Chrome	50个/每个域名	大于80000
FireFox	50个/每个域名	4097个字节