标签:
cookie是什么?是饼干,小甜点?
No! No! No! 我今天要总结的cookie并不是你所想的小甜心,我这里要说的cookie是Web开发中的一个重要的“武器”,每一个Web开发者的武器库中肯定要装备这门武器。
cookie是浏览器存储在用户电脑上的一个文本文件,里面包含一些key=value
格式的数据;浏览器按照一定的规范来管理和存储这些数据,并在之后的请求中将这些信息发送至服务器,服务器根据客户端传回的cookie数据进行用户识别、用户行为分析等操作。千言万语总结成一句话,cookie就是:
cookie是浏览器存储在用户电脑上的一些数据;每次发起请求时,浏览器都会将对应的cookie数据一起发送至服务器。
HTTP协议是无状态的,也就是说客户端和服务器端不需要建立持久的连接。由于客户端和服务器的连接是基于一种请求应答模式,及客户端和服务器建立一个连接,客户端提交一个请求,服务器端收到请求后返回一个响应,然后二者就断开连接。
既然客户端和服务器在完成一次请求以后,彼此就断开了连接,二者之间就不再有任何关系了;比如,用户在页面一进行了登录,当用户跳转到了同一个Web应用的页面二,那么如何在页面二知道用户已经进行了登录呢?It’s a question!!! 当客户端再次发起请求的时候,服务器端如何判断两次不同的请求来自同一个客户端呢?
是的,服务器无法区分每一次请求之间的联系。这就需要有一个状态来标识每一次请求,如果两次请求的状态标识是一样的,这就表明这两个请求是从同一个客户端发起的。
现在问题的焦点就是这个用来标识每一次请求的状态位如何来设计呢?这的确是一个难题,于是上帝派出了一位青年才俊的工程师来帮程序猿解决了这个问题,他就是24岁的网景公司的moutulli,他设计出了cookie的雏形。
在moutulli设计的基础上,经过多年的发展,cookie的发展的越来越规范,后来直接成为了标准。至于客户端浏览器和服务器之间到底怎么使用cookie,请继续阅读以下内容。
下面我通过浏览器向www.baidu.com发起请求,并简单的将cookie的工作原理图绘制出来。
服务器通过发送一个带有Set-Cookie
的HTTP消息响应头来创建一个cookie,并设置cookie的一些属性。
客户端通过发送一个带有Cookie: name=value;
name2=value2
的HTTP请求头来向服务器发送本地的cookie数据。
以上就是cookie在客户端和服务器之间进行传递信息的基本过程。
cookie是有生命周期的,一旦到了cookie的失效日期,客户端的cookie就会被删除。服务器在创建cookie时可以控制一个cookie可以在客户端“存活”多长时间。在以下几种情况下,cookie都会结束它自己的生命周期:
浏览器不会让cookie肆意的发展,它总会在需要的时刻出马,干掉一些cookie,结束它们的生命。
我每天要浏览那么多的网站,这个网站写两个cookie,那个网站也写两个cookie,那么浏览器中的cookie肯定会很多,那么浏览器如何管理这些cookie呢?这的确是一个问题。
首先,各大浏览器都对cookie的总个数和总大小都有限制(数据来源网络,未做验证):
主流浏览器 | IE6.0 | IE7.0/8.0 | Opera | Firefox | Safari | Chrome |
---|---|---|---|---|---|---|
cookie个数 | 每个域为20个 | 每个域为50个 | 每个域为30个 | 每个域为50个 | 没有个数限制 | 每个域为53个 |
cookie大小 | 4095个字节 | 4095个字节 | 4096个字节 | 4097个字节 | 4097个字节 | 4097个字节 |
总之,在进行cookie操作的时候,应该尽量保证cookie个数小于20个,总大小小于4KB。
除了个数和大小的管理以外,每个站点各自的写的cookie,浏览器又如何管理呢?我们在服务器端创建一个cookie的时候,一般都会指定以下两个选项:
这两个选项决定了创建的cookie属于哪个域名下的哪个位置。对于domain选项,默认情况下,domain会被设置为创建该cookie的页面所在的域名,所以当给相同域名发送请求时,该cookie会一起被发送至服务器。比如百度这样的大站,有很多的二级域名,例如:http://music.baidu.com/、http://picture.baidu.com/等,如果需要在所有的二级域名下都记录一个cookie,则需要在创建cookie的时候,将cookie的domain选项设置为baidu.com;此时域名为baidu.com下的所有二级域名都将拥有同样的一个cookie。创建域名时指定domain,这又是一个难点,经常会出现顶级域名和二级域名的cookie冲突问题。
我们在发送请求时,浏览器会把domain的值与请求的域名做一个尾部比较(即从字符串的尾部开始比较),并将匹配的cookie发送至服务器。所以以后在设计哪些数据需要写入cookie的时候,也要考虑清楚这个域名的问题。对于此,基本上总结为以下三点:
举个例子来说:
说完domain,再来说说path选项。 在创建cookie的时候,也可以指定一个path值,path选项指定了请求的资源URL中只有在存在指定的路径时,才会发送Cookie消息头,它决定了客户端发送cookie到服务器端的匹配规则。通常是将path选项的值与请求的URL从头开始逐字符比较,如果字符匹配,则发送Cookie消息头。需要注意的是,只有在domain选项满足之后才会对path属性进行比较。path属性的默认值是发送Set-Cookie消息头所对应的URL中的path部分。
以上从浏览器本身的限制和生成cookie时的选项对cookie的管理进行了简单的总结。接下来就通过一些简单的代码来演示如何创建和获取cookie。
服务器通过发送一个带有Set-Cookie
的HTTP消息响应头来创建一个cookie。例如:
创建cookie本身没有多少难点,但是在创建创建cookie的时候,我们需要明白几个选项,以及这些选项的具体作用。
名称 | 作用 |
---|---|
domain选项 | 请参见【cookie的管理】这一小节 |
path选项 | 请参见【cookie的管理】这一小节 |
maxage选项 | 设置浏览器何时删除cookie |
secure选项 | Secure字段告诉浏览器在https通道时,对Cookie进行安全加密,这样即时有黑客监听也无法获取cookie内容;默认情况下,在HTTPS连接上传输的cookie都会被自动添加上secure选项。当secure值为true时,cookie在HTTP中是无效,在HTTPS中才有效 |
httponly选项 | HttpOnly字段告诉浏览器,只有在HTTP协议下使用,对浏览器的脚本不可见,所以跨站脚本攻击时也不会被窃取,此时JS则无法访问带有httponly的cookie |
示例代码:
客户端向服务器发起请求时,在domain和path匹配的情况下,会将对应的cookie一起发送到服务器端。所以,如果一个path下设置的cookie太多,就可能出现http请求头超长的问题。
请求到达服务器端以后,我们可以这样读取cookies。
cookie作为每个Web开发人员必需要会的知识点,其中的细节有很多,而且经常得不到重视。这篇文章就对Web开发中的cookie这个知识点进行了详细的总结,每个容易忽视的细节,每个知识点都进行了详细的分析,虽然理论知识偏多,但是这些理论知识却是实践开发的基石,希望你能喜欢这篇文章。
标签:
原文地址:http://blog.csdn.net/pwescool/article/details/51938453