一句话概括RESTFUL

就是用 URL 定位资源，用 HTTP 描述操作。

XSS攻击

XSS（跨站脚本攻击）是指攻击者在返回的 HTML 中嵌入 javascript 脚本，

Cookie如何防范XSS攻击

为了减轻这些攻击，需要在 HTTP 头部配上，set-cookie： httponly-这个属性可以防止 XSS,它会禁止 javascript 脚本来访问 cookie。 secure - 这个属性告诉浏览器仅在请求为 https 的时候发送 cookie。 结果应该是这样的：Set-Cookie=<cookie-value>....

cookie_session区别

1. cookie 数据存放在客户的浏览器上，session 数据放在服务器上。
2. cookie 不是很安全，别人可以分析存放在本地的 COOKIE 并进行 COOKIE 欺骗 考虑到安全应当使用 session。
3. session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能 考虑到减轻服务器性能方面，应当使用 COOKIE。
4. 单个 cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 cookie。

Cookie_sessionStorage_localStorage的区别

共同点：

都是保存在浏览器端，并且是同源的

区别：

• cookie 数据始终在同源的 http 请求中携带（即使不需要），即 cookie 在浏览器 和服务器间来回传递。
• sessionStorage 和 localStorage 不会自动把数据发给服务器，仅 在本地保存
• cookie 数据还有路径（path）的概念，可以限制 cookie 只属于某个路径下,

fetch发送2次请求的原因

fetch 发送 post 请求的时候，总是发送 2 次，第一次状态码是 204，第二次才成功？

原因很简单，因为你用 fetch 的 post 请求的时候，导致 fetch 第一次发送了一个 Options 请求，询问服务器是否支持修改的请求头，如果服务器支持，则在第二次中发送真正的请求。

Get和Post的区别

• get 参数通过 url 传递，post 放在 request body 中。
• get 请求在 url 中传递的参数是有长度限制的，而 post 没有。
• get 比 post 更不安全，因为参数直接暴露在 url 中，所以不能用来传递敏感信息。
• get 请求只能进行 url 编码，而 post 支持多种编码方式
• get会将数据缓存起来，而post不会
• get 请求参数会被完整保留在浏览历史记录里，而 post 中的参数不会被保留。
• GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器 的限制，导致他们在应用过程中体现出一些不同。 GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。

• GET
• POST
• HEAD
• OPTIONS
• PUT
• DELETE
• TRACE
• CONNECT

HTTP强缓存和协商缓存

缓存分为两种：强缓存和协商缓存（弱缓存），根据响应的 header 内容来决定

	获取资源的形式	状态码	发送请求到服务器
强缓存	从缓存取	200（from cache）	否，直接从缓存取
协商缓存	从缓存取	304（not modified）	是通过服务器来告知缓存是否可用

HTTP常用请求头

协议头	说明
Accept	可接受的响应内容类型（Content-Types）
Accept-Charset	可接受的字符集
Accept-Encoding	可接受的响应内容的编码方式
Accept-Language	可接受的响应内容语言列表
Accept-Datetime	可接受的按照时间来表示的响应内容版本
Authorization	用于表示 HTTP 协议中需要认证资源的认证信息
Cache-Control	用来指定当前的请求/回复中的，是否使用缓存机制。
Connection	客户端（浏览器）想要优先使用的连接类型
Cookie	由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie
Content-Length	以 8 进制表示的请求体的长度
Content-MD5	请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果
Content-Type	请求体的 MIME 类型 （用于 POST 和 PUT 请求
Date	发送该消息的日期和时间（以 RFC 7231 中定义的"HTTP 日期"格式 来发送）
Expect	表示客户端要求服务器做出特定的行为
Form	发起此请求的用户的邮件地址
Host	表示服务器的域名以及服务器所监听的端口号。如果所请求的端口 是对应的服务的标准端口（80），则端口号可以省略。
If-Match	仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对 应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新 某个资源后，该资源未被修改的情况下，才更新该资源。
If-Modified-Since	允许在对应的资源未被修改的情况下返回 304 未修改
If-None-Match	允许在对应的内容未被修改的情况下返回 304 未修改（ 304 Not Modified ），参考 超文本传输协议 的实体标
If-Range	如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否 则，返回整个新的实体
If-Unmodified-Since	仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。
Max-Forwards	限制该消息可被代理及网关转发的次数。
Origin	发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加 入一个 Access-Control-Allow-Origin 的消息头，表示访问控制所允许 的来源）。
Pragma	与具体的实现相关，这些字段可能在请求/回应链中的任何时候产 生。
Proxy-Authorization	用于向代理进行认证的认证信息。
Range	表示请求某个实体的一部分，字节偏移以 0 开始。
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接 将浏览器带到了当前页面。Referer 其实是 Referrer 这个单词，但 RFC 制作标准时给拼错了，后来也就将错就错使用 Referer 了。
TE	浏览器预期接受的传输时的编码方式：可使用回应协议头 Transfer-Encoding 中的值（还可以使用"trailers"表示数据传输时的分 块方式）用来表示浏览器希望在最后一个大小为 0 的块之后还接收 到一些额外的字段。
User-Agent	浏览器的身份标识字符串
Upgrade	要求服务器升级到一个高版本协议。
Via	告诉服务器，这个请求是由哪些代理发出的。
Warning	一个一般性的警告，表示在实体内容体中可能存在错误。

301和302的区别

• 301 Moved Permanently 被请求的资源已永久移动到新位置，并且将来任何对此资源的引 用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应 当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
• 302 Found 请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的， 客户端应当继续向原有地址发送以后的请求。只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可缓存的