try again
Cookie的起源
早期的Web应用面临的最大问题之一就是如何维持状态,即服务器无法知道两个请求是否来自同一个浏览器。当时最简单的方法就是在请求的页面中插入一个token,然后在下次请求时将这个token返回至服务器,这需要通过页面的form表单或者URL的query来进行传递,手动操作容易出错。
1994年,网景通讯的Lou Montulli将"magic cookies"的概念应用到Web通讯中。他的原始说明文档提供了cookie工作原理的基本信息,该文档后来被作为规范纳入RFC 2109中,最终纳入RFC 2965。现在所有的Web浏览器都支持cookie。
Cookie详解
HTTPCookies, 通常称之为'Cookie',是在远程浏览器端存储数据并以此跟踪和识别用户的机制。从实现上来说,Cookie是存储在客户端上的一小段文本文件,浏览器通过HTTP协议和服务端进行Cookie交互,即一个Web页面或服务器告知浏览器按照一定的规范来存储这些cookie信息,并在随后的请求中将这些信息发送至服务器,服务器通过这些信息来识别不同的用户。现在大多数需要登录的网站在用户验证成功之后都会设置一个cookie,只要这个cookie存在并且有效,用户就可以自由浏览这个网站的任何页面,若cookie被删除或者过期,则需要用户重新登录。
Cookie创建
服务器通过发送名为Set-Cookie的HTTP消息头来创建一条cookie信息,其格式如下:
Set-Cookie:<cookie-name>=<cookie-value>;
Expires=<date>;
Max-Age=<non-zero-digit>;
Domian=<domain-value>;
path=<path-value>;
secure;
HttpOnly=<httponly-value>
- 消息第一部分通常是一个key=value格式的字符串,也是原始规范中指定的格式。
-
Expires为过期时间,指定了cookie何时不会再被发送至服务器,随后浏览器将会删除该cookie,该选项是一个Wdy, DD-Mon-YYYY HH:MM:SS GMT的日期格式。例如:
Set-Cookie: name=Nicholas; expires=Sat, 02 May 2009 23:38:25 GMT
-
domain指定了cookie将要被发送至哪个或者哪些域。默认情况下,domain会被设置为创建该cookie的页面所在的域名,所以给相同域名发送请求时,该cookie会被发送至服务器 -
path指定了请求资源URL中必须存在该path路径,才会发送cookie消息头。通常是将path选项的值与请求URL从头开始逐个字符比较,如果字符匹配,则发送cookie消息头。例如:
Set-Cookie:name=Nicholas;path=/blog
该例中, path 值会与 /blog , /blogtest 等相匹配,任何以 /blog 开头的选项都是符合规则的。需要注意的是,只有在 domain 选项过滤之后才会对 path 选项进行比对。
-
secure该选项只是一个标记,没有具体的值,表示一个请求只有通过SSL或者HTTPS创建时,包含secure选项的cookie才会被发送至服务器。 - HttpOnly指定该cookie无法通过JavaScript脚本读取,即
document.cookie、XMLHttpRequest对象和 Request API均无法读取cookie,只有浏览器发出HTTP请求时,才会带上该cookie。
Cookie的使用
cookie一般用于采用HTTP作为信息交换协议的客户端和服务端来记录需要持久化的信息。一般由服务端创建,传递到客户端,客户端从HTTP消息中读取cookie信息,并保存到本地,当客户端再次访问服务器时,会从本地读取存储的cookie信息,附加到HTTP消息中发送请求,服务端再从接收到的HTTP消息中读取cookie,进行下一步操作。
由于cookie信息以明文方式保存在文本文件中，对一些敏感信息如口令、银行帐号如果要保存在本地cookie文件中，最好采用加密形式。
与cookie类似的另一个概念是会话（Session），会话一般是记录客户端和服务器端从客户端浏览器连接上服务器端到关闭浏览器期间的持久信息。会话一般保存在内存中，不保存到磁盘上。会话可以通过cookie机制来实现，对于不支持cookie的客户端，会话可以采用URL重写方式来实现。可以将会话理解为内存中的cookie。
使用会话会对系统伸缩性造成负面影响，当服务器端要在很多台服务器上同步复制会话对象时，系统性能会受到较大伤害，尤其会话对象较大时。这种情况下可以采用cookie，将需要记录的信息保存在客户端，每次请求时发送到服务器端，服务器端不保留状态信息，避免在服务器端多台机器上复制会话而造成的性能下降
Cookie路径概念
cookie 一般都是由于用户访问页面而被创建的，可是并不是只有在创建 cookie 的页面才可以访问这个 cookie。
默认情况下，只有与创建 cookie 的页面在同一个目录或子目录下的网页才可以访问，这个是因为安全方面的考虑，造成不是所有页面都可以随意访问其他页面创建的 cookie。举个例子：
在 "https://www.jianshu.com/u/" 这个页面创建一个cookie，那么在"/u/"这个路径下的页面如： "https://www.jianshu.com/u/cb09084735af"这个页面默认就能取到cookie信息。
可在默认情况下， "https://www.jianshu.com"或者 "https://www.jianshu.com/xxxx/" 就不可以访问这个 cookie（光看没用，实践出真理_）。
那么如何让这个 cookie 能被其他目录或者父级的目录访问类，通过修改 cookie 的路径就可以实现。例子如下
document.cookie = "name=value;path=superpath/otherpath"
最常用的是让cookie在根目录下,不管在哪个页面创建cookie,所有页面都可以使用
document.cookie = "name=Darren;path=/"
Cookie域概念
同域之间cookie共享可以通过domain属性实现,例如:"www.qq.com" 与 "sports.qq.com" 公用一个关联的域名"qq.com"，我们如果想让 "sports.qq.com" 下的cookie被 "www.qq.com" 访问，我们就需要用到 cookie 的domain属性，并且需要把path属性设置为 "/"。例：
document.cookie = "username=Darren;path=/;domain=qq.com"
注：一定的是同域之间的访问，不能把domain的值设置成非主域的域名,会造成cookie污染。
Cookie安全性
通常 cookie 信息都是使用HTTP连接传递数据，这种传递方式很容易被查看，所以 cookie存储的信息容易被窃取。假如 cookie 中所传递的内容比较重要，那么就要求使用加密的数据传输。
cookie 的属性“secure”，默认的值为空。如果一个 cookie 的属性为secure，那么它与服务器之间就通过HTTPS或者其它安全协议传递数据。语法如下：
document.cookie = "username=Darren;secure"
把cookie设置为secure，只保证 cookie 与服务器之间的数据传输过程加密，而保存在本地的 cookie文件并不加密。如果想让本地cookie也加密，得自己加密数据。
注：就算设置了secure 属性也并不代表他人不能看到你机器本地保存的 cookie 信息，所以说到底，别把重要信息放cookie就对了，囧...
Cookie自动删除
cookie会被浏览器自动删除,有几下几个原因:
- 会话cookie(Session cookie)会在会话结束时(浏览器关闭)被删除
- 持久化cookie(Persistent cookie)在达到失效日期时被删除
- 如果浏览器中cookie数量达到限制,那么cookie会被删除以为新的cookie创建空间
对于自动删除来说,Cookie管理十分重要,因为这些删除都是无意识的.
Cookie的限制条件
- cookie属性:
- cookie的大小:原始规范中限定每个域名下不超过 20 个 cookie，早期的浏览器都遵循该规范，并且在 IE7 中有更近一步的提升。在微软的一次更新中，他们在 IE7 中增加 cookie 的限制数量到 50 个，与此同时 Opera 限定 cookie 数量为 30 个，Safari 和 Chrome 对与每个域名下的 cookie 个数没有限制。
发向服务器的所有 cookie 的最大数量（空间）仍旧维持原始规范中所指出的：4KB。所有超出该限制的 cookie 都会被截掉并且不会发送至服务器
网友评论