HTML5学习笔记（二十九）：Cookie和Session

HTTP协议自己是无状态的，这和HTTP最初的设计是相符的，每次请求都是建立一个短链接，发送请求，获得数据后就关闭链接。即每次链接都是独立的一次链接。

这样的话，致使的问题就是当我在一个页面登录了帐号以后，点击链接打开的新界面或者关闭后再打开我都须要再次登录帐号，因此咱们须要借助Cookie和Session来记录网页的状态。

Cookie

Cookie，有时也用其复数形式 Cookies。能够简单的理解为存储在浏览器的文本数据。

Cookie按域名来进行存储，不一样的域名存储的Cookie相互之间不能访问时隔绝的。而在当前域名存在Cookie时，每次向服务端进行请求时都会在HTTP请求头中，把当前域名下的全部Cookie都一块儿进行提交。这样服务端就能够获取当前网站存储的全部Cookie数据。而服务端在进行返回时也能够在HTTP响应头中附带上新的Cookie，浏览器接收到返回时，会保存服务端发送的Cookie，这样下次请求，服务端又能够得到新发送的Cookie数据。

下面咱们来详细的看看Cookie的一些特性。

不可跨域名

根据Cookie的规范，这是由Cookie的隐私安全机制决定的。隐私安全机制可以禁止网站非法获取其余网站的Cookie。不一样域名的网站下面的Cookie是互相不能访问的，你当前在cnblog下，就不能获取和操做的baidu的Cookie，这是比较好理解的。

域名

正常状况下，同一个一级域名下的两个二级域名如www.baidu.com和images.baidu.com也不能交互使用Cookie，由于两者的域名并不严格相同。

若是想全部baidu.com名下的二级域名均可以使用该Cookie，须要设置Cookie的domain参数为.baidu.com。这样全部二级三级域名，均可以访问这个Cookie。

注意：domain参数必须以点(".")开始。

路径

domain属性决定运行访问Cookie的域名，而path属性决定容许访问Cookie的路径。

例如，若是只容许/session/下的程序使用Cookie，能够设定path参数为/session/。

设置为“/”时容许全部路径使用Cookie。path属性须要使用符号“/”结尾。

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

有效期

Cookie的maxAge决定着Cookie的有效期，单位为秒（Second）。

若是maxAge属性为正数，则表示该Cookie会在maxAge秒以后自动失效。浏览器会将maxAge为正数的Cookie持久化，即写到对应的Cookie文件中。不管客户关闭了浏览器仍是电脑，只要还在maxAge秒以前，登陆网站时该Cookie仍然有效。

若是maxAge为负数，则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该Cookie即失效。maxAge为负数的Cookie，为临时性Cookie，不会被持久化，不会被写到Cookie文件中。

若是maxAge为0，则表示删除该Cookie。Cookie机制没有提供删除Cookie的方法，所以经过设置该Cookie即时失效实现删除Cookie的效果。失效的Cookie会被浏览器从Cookie文件或者内存中删除。

Cookie默认的maxAge值为–1。

安全属性

HTTP协议不只是无状态的，并且是不安全的。使用HTTP协议的数据不通过任何加密就直接在网络上传播，有被截获的可能。使用HTTP协议传输很机密的内容是一种隐患。若是不但愿Cookie在HTTP等非安全协议中传输，能够设置Cookie的secure属性为true。浏览器只会在HTTPS和SSL等安全协议中传输此类Cookie。

提示：secure属性并不能对Cookie内容加密，于是不能保证绝对的安全性。若是须要高安全性，须要在程序中对Cookie内容加密、解密，以防泄密。

存储中文和图片

中文须要使用escape和unescape两个方法进行编码和解码，不然会出现乱码。

图片可使用Base64编码为字符串来保存。

浏览器发送cookie规则

在发起一个请求时，浏览器会选择什么样的Cookie数据传递到服务端呢？

根据请求url中的域名在cookie列表中找全部与当前域名同样的cookie，而后再根据指定的路径进行匹配，若是当前请求在域匹配的基础上还与路径匹配那么就会将全部匹配的cookie发送给服务器。

也能够手动指定cookie的适用的域（domain），而后手动指定路径（path）。

一些须要注意的地方

• 可能会被用户禁用：Cookie是保存在浏览器端的，因此用户有权利选择关闭Cookie。
• 存储大小有限制：不一样的浏览器都对Cookie的存储大小有限制，Cookie不宜存储过多的数据。
• 容易被删除：用户能够随时清空Cookie。
• 安全性不够高：Cookie是用明文的方式存储的，不适合保存敏感的数据。

Session

在Web端保存用户状态的方式除了Cookie外，还可使用Session来进行保存，不一样的是Cookie保存在浏览器，而Session保存在服务端。

Session的存取都只能在服务端进行操做，因此浏览器是不能直接对Session的数据进行读取和操做的（间接固然是能够的，浏览器能够发送数据给服务端用来存Session的值，服务端也能够直接把Session的值做为返回值返回到浏览器）。

惟一要解决的问题就是，由于每次请求都是独立的，因此服务端须要知道每次的请求的身份，好比我和李雷同时请求，服务端须要知道那些请求是个人，那些是李雷的。

解决这个问题的方式通常以下：当服务端开始使用Session时，会生成一个guid用来标记本次请求的客户端，能够把这个guid看作是这个客户端的id，而后，会把这个guid做为Cookie发送给浏览器。浏览器会自动保存这个guid，下次客户端再次请求时，这个Cookie会传递给服务端，服务端获得guid后，就能够获取以前的Session的全部数据了。

示例

下面咱们以NodeJS的Express框架为例，来看一下Session的例子。

咱们第一次请求时，浏览器的请求头没有包含任何的Cookie信息，可是服务端的响应头里包含了一个名为connect.sid的Cookie信息返回到浏览器，这个connect.sid就是服务端生成的SessionID。

后续的请求，浏览器的请求头中就会包含名为connect.sid的SessionID，服务端能够知道当前请求的SessionID，就能够获取前面请求保存的数据了，因为浏览器已经有了SessionID，那么本次的服务端响应头的Cookie就没有再发送connect.sid到浏览器了。

有效期

Session在设定时，都有一个有效时间（这个时间通常均可以配置，不一样的语言框架配置方式各异），实际上就是传递到浏览器的Cookie的有效时间，因为Session通常存放在服务端的内存中，若是不清除则会致使内存占用愈来愈多，最终整个服务器奔溃。因此服务端会在必定的时间清除过时或者长时间不使用的Session及数据。

URL地址重写

因为Cookie能够被人为的禁止，必须有其余机制以便在Cookie被禁止时仍然可以把SessionID传递回服务器。常常被使用的一种技术叫作URL重写，就是把SessionID直接附加在URL路径的后面，附加方式也有两种，一种是做为URL路径的附加信息，表现形式为http://...../xxx;sessionid=ByOK ... 99zWpBng!-145788764，另外一种是做为查询字符串附加在URL后面，表现形式为http://...../xxx?sessionid=ByOK ... 99zWpBng!-145788764

这两种方式对于用户来讲是没有区别的，只是服务器在解析的时候处理的方式不一样，采用第一种方式也有利于把SessionID的信息和正常程序参数区分开来。