document.cookie(使用场景有什么区别)

1. document.cookie，使用场景有什么区别？

万维网（www：World Wide Web）的诞生起源自1990年12月15日蒂姆·伯纳斯·李利用网际网络实现了超文本传输协议（http：Hyper Text Transfer Protocol）客户端和服务器的第一次通讯。

http是运行在TCP之上的一种简单的请求、响应协议，所谓的协议就是形成了固有的套路，客户端指定向服务器发送什么信息，然后服务器就会做出与之对应的回应。

举个例子：GET、POST、HEAD等方法中，post一般用于客户端提交表单数据给服务器，或者上次文件给服务器，而head、get则是获取URL中指定的资源。在使用get时请求的参数、值需要附加在URI(URI时URL的一种扩张，在HTTP协议中URI一般都是指URL)后面，利用"?"将资源的URI和请求参数、值隔离开来，参数、值之间使用“&”隔开。

万维网的发展历史要彻底理解session、cookie、token之间的区别，就不得不去翻开过去尘封的历史。仅30年web发生了翻天覆地的变化。

早期的web其实是非常简陋的，仅仅实现的是基本的文本浏览而已。用寒酸的表格来做框架定位还仅仅是后话。仅仅只是文本和文本包含的超链接而已，服务器仅仅只是机械式的请求，然后响应，并不需要记录谁在某一个时间段里浏览了什么内容，也不需要记住是谁发的HTTP请求。

慢慢的网站就需要登录、留言、发表内容、内容管理、在线购物等等交互，这时web就需要引入会话管理机制，记录谁登录了系统，谁又将商品放入了购物车中等等。由于早期的web本身就是无状态请求，于是有人就想出了一个办法，给每个访问的人发一个不会重复的号码牌，也就是session id（会话标识）。由于session id是服务器发给每个接收端的一串随机字符串，这样就能够区分谁是谁了。

session id看似解决web无状态请求的问题，但也造成了不小的困扰。比如在负载均衡组成的集群中，当我们通过机器A登录，session id就会保持在机器A上。但如果下次请求转发到了机器B，就需要将机器A的session id复制到机器B上，所以总是在session复制、粘贴的过程，如果保存了session的机器挂了新的问题接着又产生了。

除此之外每个人的设备确实是保存了属于自己的session id，但服务器却要保存所有的session id，这可不一定是几个几十个了，二十成千上万，甚至几十、上百万个。

session其实也特别不安全，如果有人伪造了你的session id，也就意味着他可以为所欲为了。可以通过cookie的方式来保存session id，但cookie的区别在于其主要内容包括了名字、值、过期时间、路径、域等信息，cookie可以实现类似于访问者离开店铺或者关闭浏览器，再打开店铺就能马上回复购物车的功能。但cookie一旦过期就会被清理，当访问者再次打开网站时又会重新分配cookie。

这么看来session id和cookie在本质上并没有完全的区别，别人想伪造很容易伪造。于是token就出现了，比如用HMAC-SHA256算法加上一个密钥来对数据进行签名，那么别人不知道密钥，那么就没有办法伪造了，签名和数据组合在一起就是token了。

token并不需要保存，只需要将发过来的token用同样的HMAC-SHA256算法和密钥再算一次比对相同就表示这个用户已经登录了，并且可以直接取到用户的userID，相反不相同，则会提示认证失败。token的优势是非常明显的，服务器只生产token和验证token，所以服务器就变得非常轻松，没有了各种附带的状态。

但由于token中的数据也是明文保存，所以一旦某个人的token被人偷走了，和本人是一样的。

总之cookie依旧在，使用web api的互联网大厂更加热衷于token，token相对于session id、cookie会更加安全，并且无状态、可扩展，支持移动设备，可以跨程序调用。

以上个人浅见，欢迎批评指正。

认同我的看法，请点个赞再走，感谢！

喜欢我的，请关注我，再次感谢！

document.cookie(使用场景有什么区别)

2. found怎么设置浏览器？

步骤/方式一

“ERROR 404--NOT FOUND”这样的字眼是由于IE浏览器的“Internet选项”设置出了问题。先在“开始”键中点开“控制面板”，双击“Internet选项”。

步骤/方式二

在“Internet属性”中，点击“常规”，打开“语言（L）”。

步骤/方式三

除“中文｛简体，中文｝”以外的其他语言选项都要删除。做到了这些，就可以正常进入网页。

3. cookies设置允许还是不行？

之前项目有一个需求，在下载文件的时候，在向后端发出请求的这段时间要有loading动画提高交互性。

但是当时后端只能以传统的向前端发送流的形式来下载，ajax派不上用场，只能用js去模拟，但是这样就监听不到后端的返回，只能等后端将数据流发送回来，浏览器自动弹出下载提示。

想了想，只能是后端返回的时候发送一个Cookie: {downloading: true}，然后我前端轮询这个字段，轮询到就将loading关闭，并将这个cookie删除。理论上来说好像是没什么毛病，但实际应用起来还是有一些坑的。

踩坑完毕，记录一下。

首先遇到的第一个坑就是发现cookie删不掉。

当然，这里说明一下，并不是js或者浏览器本身的机制不允许删除cookie，只是我删除的方式不对。

一开始我只是简单的将cookie设置为空，将expires设置为-1。心里想着，已过期，cookie自动清除，美滋滋，然而事实并没有按照我想的发生。downloading还是躺在cookie里面没有任何变化，是因为没有刷新吗？于是我在后面再次获取了一下：

console.log(document.cookie);

发现cookie里面确实还是有downloading这个字段。

没办法，打开application看看，果然发现了问题，后端传递过来的这个cookie没有设置expires，但是却默认设置了path，再联想我之前删除的cookie是没有带任何参数的，结合cookie的机制，发现了问题所在。

解决办法：

在删除cookie的时候要加上这个字段所带的参数，可能是出于安全的考虑，不同的参数，即使名字相同，也会当成两个cookie存储，所以我删除的并不是后端传过来的cookie，自然就删除不了。

第二个坑，后端设置cookie默认的path属性没有规律。

出于代码复用和性能考虑，后端的很多功能都会集成到一个API，再加上前端可能会用到一些第三方的框架，这些框架所采用过的设计模式都各不相同，都会造成一些不可预测的结果，而项目有可能在任何地方都会有下载的需求，所以当我发现如何删除cookie的时候，我又发现了一个坑，那就是不知道该如何准确获取cookie的path属性。而且如果你请求的接口默认path与你所在的url不匹配的话，浏览器将会忽略这次的cookie设置，在我的项目的直接体现就是，后端响应了cookie，但是我前端接收不到，页面loading无法消失，卡死了。

解决办法：

根据cookie的机制，当cookie的path属性为'/'的时候，cookie就不会被忽略。

所以解决办法就是让后端在set-cookie的时候讲path设置成固定的'/'，以java为例：

Cookie cookie = new Cookie("Downloading","true");

cookie.setPath("/");

response.addCookie(cookie);

然后前端只要在监听到downloading字段的时候，再将path='/'的downloading删除就可以了。