ookie always stored in the client, according to the storage location in the client can be divided into memory and hard drive Cookie Cookie. Memory Cookie maintained by the browser, stored in memory, disappeared after the browser is closed, its existence time is short. Cookie hard disk in the hard disk, there is an expiration time, unless the user manually clean up or to the expiration time, Cookie hard disk is not deleted, its lifespan is long-term. So, by the existence of time, can be divided into non-persistent and persistent Cookie Cookie.
HTTP request + cookie exchange procedure
If step 5 is carried expired cookie or cookie is wrong, then the authentication fails, the return to the required authentication page.
As a stateless protocol HTTP protocol for HTTP protocol is stateless the same means independent of each request before the request, it does not record the current request is the last request information. So the question is, since no state, it completed a complete set of business logic, sending the case of numerous repeated requests, how to use the http request context associating it? Request information through the optimized human wit, found a simple way to record http protocol
Optimized HTTP request:
- Browser sends a request to the server request, the server returns the response request in addition to outside, a back request assigned unique identification ID, together with a synergistic response back to the browser.
- While the server creates a local MAP structure, specifically to key-value (ID- session request content) each request is stored in the form of
- At this point the browser request has already been given an ID, the second visit, the server looks up the ID start with the request, look for content based on the content of the maintenance session ID, the content recorded in the information on the status of a request.
- Find out the request based on the response information generated based on the content of the information, again returned to the browser. If there is a need to update the session content will once again offer ready for the next request.
所以根据这个会话ID，以建立多次请求-响应模式的关联数据传递。说到这里可能已经唤起了大家许多共鸣。这就是cookie和session对无状态的http协议的强大作用。服务端生成这个全局的唯一标识，传递给客户端用于唯一标记这次请求，也就是cookie；而服务器创建的那个map结构就是session。所以，cookies由服务端生成，用于标记客户端的唯一标识，无特定含义，在每次网络请求中，都会被传送。session服务端自己维护的一个map数据结构，记录key-content上下文内容状态。
cookie的属性
一般cookie所具有的属性，包括：
Domain：域，表示当前cookie所属于哪个域或子域下面。
对于服务器返回的Set-Cookie中，如果没有指定Domain的值，那么其Domain的值是默认为当前所提交的http的请求所对应的主域名的。比如访问 http://www.example.com，返回一个cookie，没有指名domain值，那么其为值为默认的www.example.com。
Path：表示cookie的所属路径。
Expire time/Max-age：表示了cookie的有效期。expire的值，是一个时间，过了这个时间，该cookie就失效了。或者是用max-age指定当前cookie是在多长时间之后而失效。如果服务器返回的一个cookie，没有指定其expire time，那么表明此cookie有效期只是当前的session，即是session cookie，当前session会话结束后，就过期了。对应的，当关闭（浏览器中）该页面的时候，此cookie就应该被浏览器所删除了。
secure：表示该cookie只能用https传输。一般用于包含认证信息的cookie，要求传输此cookie的时候，必须用https传输。
httponly：表示此cookie必须用于http或https传输。这意味着，浏览器脚本，比如javascript中，是不允许访问操作此cookie的。
服务器发送cookie给客户端
从服务器端，发送cookie给客户端，是对应的Set-Cookie。包括了对应的cookie的名称，值，以及各个属性。
Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Jan 2013 21:47:38 GMT; Path=/; Domain=.169it.com; HttpOnly
Set-Cookie: made_write_conn=1295214458; Path=/; Domain=.169it.com
Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Path=/; Domain=.169it.com; HttpOnly
从客户端把cookie发送到服务器
从客户端发送cookie给服务器的时候，是不发送cookie的各个属性的，而只是发送对应的名称和值。
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*
关于修改，设置cookie
除了服务器发送给客户端（浏览器）的时候，通过Set-Cookie，创建或更新对应的cookie之外，还可以通过浏览器内置的一些脚本，比如javascript，去设置对应的cookie，对应实现是操作js中的document.cookie。
Cookie的缺陷
- cookie会被附加在每个HTTP请求中，所以无形中增加了流量。
- 由于在HTTP请求中的cookie是明文传递的，所以安全性成问题。（除非用HTTPS)
- Cookie的大小限制在4KB左右。对于复杂的存储需求来说是不够用的。