胡熙国

网络请求

http 版本发展史

  1. http/0.9 单行协议
  • 最初版本的 HTTP 协议并没有版本号，后来它的版本号被定位在 0.9 以区分后来的版本
  • 只支持GET请求方式：由于不支持其他请求方式，因此客户端是没办法向服务端传输太多的信息
  • 没有请求头概念：所以不能在请求中指定版本号，服务端也只具有返回 HTML字符串的能力
  • 服务端相响应之后，立即关闭TCP连接
GET /index.html

响应只包含响应文档本身。

<html>
  这是一个非常简单的 HTML 页面
</html>
  1. http/1.0 构建可扩展性
  • 1996 年 5 月，HTTP/1.0 版本发布
  • 任何格式的内容都可以发送。这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件。这为互联网的大发展奠定了基础。
  • 引入了 POST 命令和 HEAD 命令
  • 通信都必须包括头信息（HTTP header），用来描述一些元数据。
  • HTTP/1.0 版的主要缺点是，每个 TCP 连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。
  • TCP 连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。
  1. http/1.1 标准化协议
  • 连接可以复用，节省了多次打开 TCP 连接加载网页文档资源的时间。
  • 增加管线化技术，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。
  • 支持响应分块。
  • 引入额外的缓存控制机制。
  • 引入内容协商机制，包括语言、编码、类型等。并允许客户端和服务器之间约定以最合适的内容进行交换。
  • 凭借 Host 标头，能够使不同域名配置在同一个 IP 地址的服务器上。
  1. http/2.0
  • 二进制分帧:HTTP 1.x 的解析是基于文本，HTTP 2之后将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，提高传输效率
  • 多路复用:在共享TCP链接的基础上同时发送请求和响应，基于二进制分帧，在同一域名下所有访问都是从同一个tcp连接中走，http消息被分解为独立的帧，乱序发送，服务端根据标识符和首部将消息重新组装起来。
  • 头部压缩:由于 HTTP 是无状态的，每一个请求都需要头部信息标识这次请求相关信息，所以会造成传输很多重复的信息，当请求数量增大的时候，消耗的资源就会慢慢积累上去。所以 HTTP 2 可以维护一个头部信息字典，差量进行更新头信息，减少头部信息传输占用的资源
  • 服务端推送:Server Push 即服务端能通过 push 的方式将客户端需要的内容预先推送过去，也叫“cache push”。 服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确地请求，服务端可以提前给客户端推送必要的资源，这样可以减少请求延迟时间，例如服务端可以主动把 JS 和 CSS 文件推送给客户端，而不是等到 HTML 解析到资源时发送请求
http1.0http1.1http2.0
连接方式非持久连接使用持久连接多路复用，持久化
请求方法GET、POST、HEADPUT、DELETE、OPTIONS无新增
缓存使用 header 里面的 If-Modified-Since 和 Expires 来作为缓存判断的标准引入了更多缓存控制策略，例如 Etag、If-Match
数据格式文本格式报文的头信息必须是文本，数据体则可以是文本也可以是二进制头信息和数据体都是二进制，统称为帧
头信息压缩不支持不支持支持
服务器推送不支持不支持支持
  • 持久连接可以使得多个 HTTP 请求复用同一个 TCP 连接，以此避免使用非持久连接时每次需要建立连接的时延

https

HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。

SSL是什么

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

浏览器在使用HTTPS传输数据的流程是什么？

  • 客户端向服务端发起建立HTTPS请求。
  • 服务器向客户端发送数字证书。
  • 客户端验证数字证书，证书验证通过后客户端生成会话密钥（双向验证则此处客户端也会向服务器发送证书）。
  • 服务器生成会话密钥（双向验证此处服务端也会对客户端的证书验证）。
  • 客户端与服务端开始进行加密会话。

11

对称加密

有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，和我们日常生活中用的钥匙作用差不多。

  • 对称加密的可行性

如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。

然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那在这个传输过程中密钥被别人劫持到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。

非对称加密

是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

  • 非对称加密的可行性

鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。

然而反过来由服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性

改良的非对称加密方案

我们已经理解通过一组公钥私钥，可以保证单个方向传输的安全性，那用两组公钥私钥，是否就能保证双向传输都安全了？

  1. 某网站服务器拥有公钥A与对应的私钥A’；浏览器拥有公钥B与对应的私钥B’。
  2. 浏览器把公钥B明文传输给服务器。
  3. 服务器把公钥A明文给传输浏览器。
  4. 之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有私钥A’，所以能保证这条数据的安全。
  5. 同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥B’解密。同上也可以保证这条数据的安全。

这样确实可以保证安全，但HTTPS的加密却没使用这种方案，为什么？很重要的原因是非对称加密算法非常耗时，而对称加密快很多。

非对称加密+对称加密

  1. 某网站拥有用于非对称加密的公钥A、私钥A’。
  2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
  3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
  4. 服务器拿到后用私钥A’解密得到密钥X。
  5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

看起来已经完美了

但是

中间人攻击

  1. 某网站有用于非对称加密的公钥A、私钥A’。
  2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
  3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
  4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
  5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
  6. 服务器拿到后用私钥A’解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是浏览器无法确认收到的公钥是不是网站自己的，因为公钥本身是明文传输的

数字证书

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就接近胜利了！

如何放防止数字证书被篡改？

我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名

数字签名

中间人有可能篡改该证书吗？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

中间人有可能把证书掉包吗？

假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？

其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

HTTPS的特证

  • 加密数据。通过TLS/SSL协议来加密数据。
  • 是第四层（传输层）协议。
  • 公钥和私钥的密钥交换发生在HTTPS中以加密和解密数据。
  • 不如HTTP轻量。当HTTPS发生加密和解密的时候，就变得笨重。
  • HTTPS在端口443监听。

本地开发配置https 证书

下载mkcert

brew install mkcert

如果只是在“单纯”的Linux或者MacOS环境中，那么只需要执行命令mkcert --install，便会在~/.local/share/mkcert目录中产生根证书rootCA-key.pem和rootCA.pem根证书文件。

在正在开发的应用程序根目录下，运行：

mkcert 127.0.0.1 localhost

应用程序中加载证书,在nest项目中src目录下新建pem文件夹，并且在nest-cli.json文件配置

{
  "$schema": "https://json.schemastore.org/nest-cli",
  "collection": "@nestjs/schematics",
  "sourceRoot": "src",
  "compilerOptions": {
    "deleteOutDir": true,
    "assets": [
      {
        "include": "**/*.pem",
        "watchAssets": true
      }
    ]
  }
}

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { readFileSync } from 'fs';
import { join, resolve } from 'path';
async function bootstrap() {
  const app = await NestFactory.create(AppModule, {
    httpsOptions: {
      key: readFileSync(
        resolve(join(__dirname, './pem/localhost.proxyman.io-key.pem')),
      ),
      cert: readFileSync(
        resolve(join(__dirname, './pem/localhost.proxyman.io.pem')),
      ),
    },
  });
  await app.listen(3000);
}
bootstrap();

http VS https

httphttps
代表超文本传输协议安全超文本传输协议
底层协议HTTP/1 和 HTTP/2 使用 TCP/IP。HTTP/3 使用 QUIC 协议。使用包含 SSL/TLS 的 HTTP/2，以进一步加密 HTTP 请求和响应
端口80443
安全性没有额外的安全功能使用 SSL 证书进行公钥加密
优势实现了通过互联网进行通信可以提高网站的权威性、可信度和搜索引擎排名

请求状态码

访问一个网页时，浏览器会向web服务器发出请求。此网页所在的服务器会返回一个包含HTTP状态码的信息头用以响应浏览器的请求。

状态码分类：

  • 1XX- 信息型，服务器收到请求，需要请求者继续操作。
  • 2XX- 成功型，请求成功收到，理解并处理。
  • 3XX - 重定向，需要进一步的操作以完成请求。
  • 4XX - 客户端错误，请求包含语法错误或无法完成请求。
  • 5XX - 服务器错误，服务器在处理请求的过程中发生了错误。

常见状态码：

  • 100 Continue: 继续，客户端应继续其请求。
  • 101 Switching Protocols: 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议。
  • 200 OK: 请求成功。一般用于GET与POST请求。
  • 201 Created: 已创建。成功请求并创建了新的资源。
  • 202 Accepted: 已接受。已经接受请求，但未处理完成。
  • 203 Non-Authoritative Information: 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本。
  • 204 No Content: 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档。
  • 205 Reset Content: 重置内容。服务器处理成功，用户终端应重置文档视图。可通过此返回码清除浏览器的表单域。
  • 206 Partial Content: 部分内容。服务器成功处理了部分GET请求。
  • 300 Multiple Choices: 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端选择。
  • 301 Moved Permanently: 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替。
  • 302 Found: 临时移动，与301类似，但资源只是临时被移动，客户端应继续使用原有URI。
  • 303 See Other: 查看其它地址。与301类似。使用GET和POST请求查看。
  • 304 Not Modified: 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。
  • 305 Use Proxy: 使用代理，所请求的资源必须通过代理访问。
  • 306 Unused: 已经被废弃的HTTP状态码。
  • 307 Temporary Redirect: 临时重定向，与302类似。使用GET请求重定向。
  • 400 Bad Request: 客户端请求的语法错误，服务器无法理解。
  • 401 Unauthorized: 请求要求用户的身份认证。
  • 402 Payment Required: 保留，将来使用。
  • 403 Forbidden: 服务器理解请求客户端的请求，但是拒绝执行此请求。
  • 404 Not Found: 服务器无法根据客户端的请求找到资源。
  • 405 Method Not Allowed: 客户端请求中的方法被禁止。
  • 406 Not Acceptable: 服务器无法根据客户端请求的内容特性完成请求。
  • 407 Proxy Authentication Required: 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权。
  • 408 Request Time-out: 服务器等待客户端发送的请求时间过长，超时。
  • 409 Conflict: 服务器完成客户端的PUT 请求时可能返回此代码，服务器处理请求时发生了冲突。
  • 410 Gone: 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置。
  • 411 Length Required: 服务器无法处理客户端发送的不带Content-Length的请求信息。
  • 412 Precondition Failed: 客户端请求信息的先决条件错误。
  • 413 Request Entity Too Large: 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息。
  • 414 Request-URI Too Large: 请求的URI过长，服务器无法处理。
  • 415 Unsupported Media Type: 服务器无法处理请求附带的媒体格式。
  • 416 Requested range not satisfiable: 客户端请求的范围无效。
  • 417 Expectation Failed: 服务器无法满足Expect的请求头信息。
  • 500 Internal Server Error: 服务器内部错误，无法完成请求。
  • 501 Not Implemented: 服务器不支持请求的功能，无法完成请求。
  • 502 Bad Gateway: 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应。
  • 503 Service Unavailable: 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
  • 504 Gateway Time-out: 充当网关或代理的服务器，未及时从远端服务器获取请求。
  • 505 HTTP Version not supported: 服务器不支持请求的HTTP协议的版本，无法完成处理。

请求方式

  • GET: 请求指定的页面信息，并返回实体主体。由于各浏览器对于URL的长度都有限制，一般使用不超过4K。
  • POST: 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中，POST 请求可能会导致新的资源的建立和/或已有资源的修改，其请求携带的最大资源大小由服务器设定。
  • HEAD: 类似于GET请求，只不过返回的响应中没有具体的内容，用于获取报头。
  • PUT: 从客户端向服务器传送的数据取代指定的文档的内容。
  • DELETE: 请求服务器删除指定的页面。
  • CONNECT: 可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道tunnel。
  • OPTIONS: 用于获取目的资源所支持的通信选项。
  • TRACE: 实现沿通向目标资源的路径的消息环回loop-back测试 ，提供了一种实用的debug 机制。
  • PATCH: 是对PUT方法的补充，用来对已知资源进行局部更新 。

缓存

浏览器缓存是浏览器在本地磁盘对用户最近请求过的资源进行存储，当访问者再次访问同一资源时，浏览器就可以直接从本地磁盘加载资源，通过缓存的方式就可以减少与服务器的数据传输，减少服务器的负担，加快页面响应速度等。

强缓存

强缓存是通过Expires与Cache-Control来控制缓存在本地的有效期。

  • Expires

Expires是HTTP 1.0提出的一个表示资源过期时间的Header，它描述的是一个绝对时间，由服务器返回。Expires受限于本地时间，如果修改了本地时间，可能会造成缓存失效.对于资源的请求，如果在Expires之内，则浏览器会直接读取缓存，不再请求服务器。

  • Cache-Control

Cache-Control出现于HTTP 1.1，优先级高于Expires，表示的是相对时间，请求头和响应头都支持这个属性，通过它提供的不同的值来定义缓存策略。

  • Cache-Control: no-store: 缓存中不得存储任何关于客户端请求和服务端响应的内容，每次由客户端发起的请求都会下载完整的响应内容。
  • Cache-Control: no-cache: 缓存中会存储服务端响应的内容，只是在与服务端进行新鲜度再验证之前，该缓存不能够提供给浏览器使用。简单来说，就是浏览器会将服务端响应的资源进行缓存，但是在每次请求时，缓存都要向服务端评估缓存响应的有效性，协商缓存是否可用，根据响应是304还是200判断是使用本地缓存资源还是使用服务器响应的资源。
  • Cache-Control: public || private: public表示该响应可以被任何中间人比如中间代理、CDN等缓存。默认响应为private，private表示该响应是专用的，中间人不能缓存此响应，该响应只能应用于浏览器私有缓存中。
  • Cache-Control: max-age=31536000: 响应为最大的过期时间，其指令是max-age=<seconds>，表示资源能够被缓存即保持新鲜的最大时间，max-age是距离请求发起的时间的秒数。
  • Cache-Control: must-revalidate: 当使用了must-revalidate指令，那就意味着缓存在考虑使用一个陈旧的资源时，必须先验证它的状态，已过期的缓存将不被使用。在正常情况下是没有必要使用这个指令的，因为在强缓存过期的情况下会进行协商缓存，但是HTTP规范是允许客户端在某些特殊情况下直接使用过期缓存的，比如校验请求发送失败的时候，还比如有配置一些特殊指令stale-while-revalidate、stale-if-error等的时候，must-revalidate指令就是让缓存在过期后的任何情况下都必须重新验证。

协商缓存

当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中，如果协商缓存命中，请求响应返回的HTTP状态为304 (Not Modified)，该请求不携带实体数据，若未命中，则返回200并携带资源实体数据。协商缓存是利用的是Last-Modified，If-Modified-Since和ETag、If-None-Match这两对Header来管理的。

请求头

  • Accept: 指定客户端能够接收的内容类型。
  • Accept-Charset: 浏览器可以接受的字符编码集。
  • Accept-Encoding: 指定浏览器可以支持的web服务器返回内容压缩编码类型。
  • Accept-Language: 浏览器可接受的语言。
  • Accept-Ranges: 可以请求网页实体的一个或者多个子范围字段。
  • Authorization: HTTP授权的授权证书。
  • Cache-Control: 指定请求和响应遵循的缓存机制。
  • Connection: 表示是否需要持久连接。
  • Cookie: HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。
  • Content-Length: 请求的内容长度。
  • Content-Type: 请求的与实体对应的MIME信息。
  • Date: 请求发送的日期和时间。
  • Expect: 请求的特定的服务器行为。
  • From: 发出请求的用户的Email。
  • Host: 指定请求的服务器的域名和端口号。
  • If-Match: HTTP请求报头使得所述请求为条件。对于GET和HEAD方法，服务器将只在与请求的资源匹配时发回请求的资源ETags。对于PUT和其他非安全方法，在这种情况下它只会上传资源。
  • If-Modified-Since: 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码。
  • If-None-Match: 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变。
  • If-Range: 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体，参数也为Etag。
  • If-Unmodified-Since: 只在实体在指定时间之后未被修改才请求成功。
  • Max-Forwards: 限制信息通过代理和网关传送的时间。
  • Pragma: 用来包含实现特定的指令。
  • Proxy-Authorization: 包含用于向代理服务器认证用户代理的凭证，通常在服务器响应407 Proxy Authentication Required状态和Proxy-Authenticate标题后。
  • Range: 只请求实体的一部分，指定范围
  • Referer: 先前网页的地址，当前请求网页紧随其后，即来路。
  • TE: 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息。
  • Upgrade: 向服务器指定某种传输协议以便服务器进行转换(如果支持)。
  • User-Agent: User-Agent的内容包含发出请求的用户信息。
  • Via: 通知中间网关或代理服务器地址，通信协议。
  • Warning: 关于消息实体的警告信息。
  • X-Forwarded-For: XFF是用于通过HTTP代理或负载平衡器识别连接到web服务器的客户端的发起IP地址的事实上的标准报头。
  • X-Forwarded-Host: XFH是用于识别由客户机在所要求的原始主机一个事实上的标准报头Host的HTTP请求报头。
  • X-Forwarded-Proto: XFP用于识别协议HTTP或HTTPS，其中使用的客户端连接到代理或负载平衡器一个事实上的标准报头。

响应头

  • Accept-Ranges: 表明服务器是否支持指定范围请求及哪种类型的分段请求。
  • Age: 从原始服务器到代理缓存形成的估算时间。
  • Allow: 对某网络资源的有效的请求行为，不允许则返回405。
  • Cache-Control: 告诉所有的缓存机制是否可以缓存及哪种类型。
  • Content-Encoding: web服务器支持的返回内容压缩编码类型。
  • Content-Language: 响应体的语言。
  • Content-Length: 响应体的长度。
  • Content-Location: 请求资源可替代的备用的另一地址。
  • Content-MD5: 返回资源的MD5校验值。
  • Content-Range: 在整个返回体中本部分的字节位置。
  • Content-Type: 返回内容的MIME类型。
  • Date: 原始服务器消息发出的时间。
  • ETag: 请求变量的实体标签的当前值。
  • Expires: 响应过期的日期和时间。
  • Last-Modified: 请求资源的最后修改时间。
  • Location: 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源。
  • Pragma: 包括实现特定的指令，它可应用到响应链上的任何接收方。
  • Proxy-Authenticate: 它指出认证方案和可应用到代理的该URL上的参数。
  • refresh: 应用于重定向或一个新的资源被创造，在5秒之后重定向。
  • Retry-After: 如果实体暂时不可取，通知客户端在指定时间之后再次尝试。
  • Server: web服务器软件名称。
  • Set-Cookie: 设置Http Cookie。
  • Trailer: 指出头域在分块传输编码的尾部存在。
  • Transfer-Encoding: 文件传输编码。
  • Vary: 告诉下游代理是使用缓存响应还是从原始服务器请求。
  • Via: 告知代理客户端响应是通过哪里发送的。
  • Warning: 警告实体可能存在的问题。
  • WWW-Authenticate: 表明客户端请求实体应该使用的授权方案。
  • X-Frame-Options: 可以被用来指示一个浏览器是否应该被允许在一个以呈现页面<frame>，<iframe>或<object>。通过确保其内容未嵌入其他网站，网站可以使用此功能来避免点击劫持攻击。
  • X-XSS-Protection: 可在检测到反射的跨站点脚本XSS攻击时阻止页面加载。
贡献者: huxiguo