Cookie & 浏览器Header缓存设置

Posted 2023-04-25

参考技术A

由于HTTP无状态协议，有时需要保存资源状态信息或者用户信息，根据状态判断是否需要重新请求资源或者在相同域名和端口下读取用户信息。

缓存可以使浏览器重用已获取的资源和保存用户信息，优化静态资源的加载速度以及加速页面的渲染速度。

缓存包括很多方面，这里仅简要介绍下数据缓存Cookie及相关设置和浏览器header缓存匹配策略(ETag, Cache-Control)

一般Cookie是由首次请求时, 服务器在HTTP的响应头通过Set-Cookie给客户端的一串字符串及metadata，比如用户信息或资源状态信息或对缓存的控制信息等，浏览器收到响应后，会将Cookie保存在客户端一段时间，然后客户端每次访问的相同域名的网页时，浏览器会按照一定的原则(浏览器缓存策略)将Cookie发送给服务器。

Cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围

注意 ：

早期HTTP /1.0中则通过服务器在Header中Set-Cookie设置 Expires 来实现缓存控制，表示资源到什么时候过期(绝对时间)，一旦修改本地时间，可能造成缓存失效。

早期HTTP /1.0使用首次响应返回Last-Modified，接下来请求头加上If-Modified-Since来实现协商缓存，相比ETag基于内容是否变更，其是否刷新缓存是通过修改时间是否变更来判断。有以下缺点：

若两者同时使用，则ETag优先级比Last Modified要高

注意：

跨域验证cookie与缓存控制

1. 是否能跨域完全取决于浏览器控制，浏览器可以直接拒绝发送跨域请求（服务器根本收不到），也可以发送给服务器等接收到返回信息后决定是否让它被读取。

2. 服务器并不能辨别请求是从哪个源发过来的，只有在客户端能够知道，因此浏览器承担起了这个责任，对于跨域ajax请求会自动添加origin头部，让服务器能够知道请求来自一个陌生的源。如果服务器觉得该源可信任，需要在response-header中增加字段Access-Control-Allow-Origin，告诉浏览器可以让请求源读取返回的报文。（也就是说，服务器一定是会返回响应的，但如果没有跨域字段的授权，该响应被浏览器拦截，不会交到请求源手里。）

3. 如果自己编写一个浏览器，完全可以避开跨域的控制，这样服务器是无法分辨请求来自哪里的，因此对于重要资源，服务器端还应另外增加验证措施（如cookie或指令等），不能完全依靠浏览器。

应用场景：代理请求到线上服务器请求数据(从Localhost: 源发送的)，会遇到跨域用户验证的问题。

4.客户端的脚本也可以做一些简单验证，前端路由可以在请求发送前，重定向未通过验证的页面(如重定向到登陆页面，被中断的导航实际是没有发送请求的)，没有在前端js里控制的url（如一些请求JSON的接口url），是不能通过前端验证登陆状态的。

5.由服务器通过response-header中set-cookie而写入的cookie会有httponly属性，通过js是无法操作读写的，而js可以写入新的cookie，在下次发送请求时在request-header中一并发送给服务器。

6.缓存控制。request和response的header中都会有cache-control，response中的表示授意浏览器的操作，request中的表示浏览器本次的实际操作。如ctrl+F5(或控制台设置disabled cache后) 发送的request head里就会有cache-control:no-cache，表示本次请求浏览器不使用缓存，类似还有cache-control:max-age=0，表示本次将与服务器协商。