HTTP | Shawnchen / XMU 。

Overview of HTTP

HTTP is an application-layer protocol for transmitting hypermedia documents.

HTTP follows a classical client-server model, with a client opening a connection to make a request, then waiting until it receives a response.

HTTP is a stateless protocol, meaning that the server does not keep any data (state) between two requests.

HTTP Cache

HTTP 缓存 (google)
HTTP caching (MDN)

缓存控制

`Cache-control`

HTTP/1.1 定义的 Cache-Control 头用来区分对缓存机制的支持情况，请求头和响应头都支持这个属性。通过它提供的不同的值来定义缓存策略。

用法

# 禁止进行缓存
# 缓存中不得存储任何关于客户端请求和服务端响应的内容。
# 每次由客户端发起的请求都会下载完整的响应内容。
Cache-Control: no-store

# 强制确认缓存
# 此方式下，每次有请求发出时，缓存会将此请求发到服务器（该请求应该会带有与本地缓存相关的验证字段）
# 服务器端会验证请求中所描述的缓存是否过期，若未过期（注：实际就是返回304），则缓存才使用本地缓存副本
Cache-Control: no-cache

# 私有缓存和公共缓存
# "public" 指令表示该响应可以被任何中间人（比如中间代理、CDN等）缓存。
# 若指定了"public"，则一些通常不被中间人缓存的页面（因为默认是private）
# 比如 带有HTTP验证信息（帐号密码）的页面 或 某些特定状态码的页面，将会被其缓存。
# 而 "private" 则表示该响应是专用于某单个用户的
# 中间人不能缓存此响应，该响应只能应用于浏览器私有缓存中。
Cache-Control: private
Cache-Control: public

# 缓存过期机制
# 过期机制中，最重要的指令是 "max-age=<seconds>"
# 表示资源能够被缓存（保持新鲜）的最大时间。
# 相对Expires而言，max-age是距离请求发起的时间的秒数。
# 针对应用中那些不会改变的文件，通常可以手动设置一定的时长以保证缓存有效
# 例如图片、css、js等静态资源。
Cache-Control: max-age=31536000

# 缓存验证确认
# 当使用了 "must-revalidate" 指令
# 那就意味着缓存在考虑使用一个陈旧的资源时，必须先验证它的状态
# 已过期的缓存将不被使用
Cache-Control: must-revalidate

`Pragma`

Pragma 是 HTTP/1.0 标准中定义的一个 header 属性，请求中包含 Pragma 的效果跟在头信息中定义 Cache-Control: no-cache 相同，但是 HTTP 的响应头不支持这个属性，所以它不能拿来完全替代 HTTP/1.1 中定义的 Cache-control 头。通常定义 Pragma 以向后兼容基于 HTTP/1.0 的客户端

新鲜度

定义

理论上来讲，当一个资源被缓存存储后，该资源应该可以被永久存储在缓存中。由于缓存只有有限的空间用于存储资源副本，所以缓存会定期地将一些副本删除，这个过程叫做缓存驱逐。

另一方面，当服务器上面的资源进行了更新，那么缓存中的对应资源也应该被更新，由于 HTTP 是 C/S 模式的协议，服务器更新一个资源时，不可能直接通知客户端及其缓存，所以双方必须为该资源约定一个过期时间，在该过期时间之前，该资源（缓存副本）就是新鲜的，当过了过期时间后，该资源（缓存副本）则变为陈旧的。驱逐算法用于将陈旧的资源（缓存副本）替换为新鲜的.

注意，一个陈旧的资源（缓存副本）是不会直接被清除或忽略的，当客户端发起一个请求时，缓存检索到已有一个对应的陈旧资源（缓存副本），则缓存会先将此请求附加一个 If-None-Match 头，然后发给目标服务器，以此来检查该资源副本是否是依然还是算新鲜的，若服务器返回了 304 (Not Modified)（该响应不会有带有实体信息），则表示此资源副本是新鲜的，这样一来，可以节省一些带宽。若服务器通过 If-None-Match 或 If-Modified-Since 判断后发现已过期，那么会带有该资源的实体内容返回。

对于含有特定头信息的请求，会去计算缓存寿命。比如 Cache-control: max-age=N 的头，相应的缓存的寿命就是 N。通常情况下，对于不含这个属性的请求则会去查看是否包含 Expires 属性，通过比较 Expires 的值和头里面 Date 属性的值来判断是否缓存还有效。如果 max-age 和 expires 属性都没有，找找头里的 Last-Modified 信息。如果有，缓存的寿命就等于头里面 Date 的值减去 Last-Modified 的值除以 10（注：根据 rfc2626 其实也就是乘以 10%）。

缓存失效时间计算公式如下：

1	expirationTime = responseTime + freshnessLifetime - currentAge

上式中，responseTime 表示浏览器接收到此响应的那个时间点。

定义最佳 Cache-Control 策略

缓存验证

用户点击刷新按钮时会开始缓存验证。如果缓存的响应头信息里含有 Cache-control: must-revalidate 的定义，在浏览的过程中也会触发缓存验证。另外，在浏览器偏好设置里设置Advanced -> Cache 为强制验证缓存也能达到相同的效果。

当缓存的文档过期后，需要进行缓存验证或者重新获取资源。只有在服务器返回强校验器或者弱校验器时才会进行验证。

ETag
作为缓存的一种强校验器，ETag 响应头是一个对用户代理不透明（UA 无需理解，只需要按规定使用即可）的值。对于像浏览器这样的 HTTP UA，不知道 ETag 代表什么，不能预测它的值是多少。如果资源请求的响应头里含有 ETag，客户端可以在后续的请求的头中带上 If-None-Match 头来验证缓存。

Last-Modified
Last-Modified 响应头可以作为一种弱校验器。说它弱是因为它只能精确到一秒。如果响应头里含有这个信息，客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存。

当向服务端发起缓存校验的请求时，服务端会返回 200 ok 表示返回正常的结果或者 304 Not Modified(不返回body)表示浏览器可以使用本地缓存文件。304的响应头也可以同时更新缓存文档的过期时间。

带 Vary 头的响应

Vary HTTP 响应头决定了对于后续的请求头，如何判断是请求一个新的资源还是使用缓存的文件。

当缓存服务器收到一个请求，只有当前的请求和原始（缓存）的请求头跟缓存的响应头里的 Vary 都匹配，才能使用缓存的响应。

使用 vary 头有利于内容服务的动态多样性。例如，使用 Vary: User-Agent 头，缓存服务器需要通过 UA 判断是否使用缓存的页面。如果需要区分移动端和桌面端的展示内容，利用这种方式就能避免在不同的终端展示错误的布局。另外，它可以帮助 Google 或者其他搜索引擎更好地发现页面的移动版本，并且告诉搜索引擎没有引入 Cloaking。

HTTP Cookies

HTTP Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。

Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

用途

Cookie 主要用于以下三个方面：

会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）

当服务器收到 HTTP 请求时，服务器可以在响应头里面添加一个 Set-Cookie 选项。浏览器收到响应后通常会保存下 Cookie，之后对该服务器每一次请求中都通过 Cookie 请求头部将 Cookie 信息发送给服务器。另外，Cookie 的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

`Set-Cookie` 响应头部和 `Cookie` 请求头部

一个简单的 Cookie 可能像这样：

1	Set-Cookie: <cookie名>=<cookie值>

服务器通过该头部告知客户端保存 Cookie 信息。

现在，对该服务器发起的每一次新请求，浏览器都会将之前保存的 Cookie 信息通过 Cookie 请求头部再发送给服务器。

会话期 Cookie 是最简单的 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。会话期 Cookie 不需要指定过期时间（Expires）或者有效期（Max-Age）。需要注意的是，有些浏览器提供了会话恢复功能，这种情况下即使关闭了浏览器，会话期 Cookie 也会被保留下来，就好像浏览器从来没有关闭一样。

和关闭浏览器便失效的会话期 Cookie 不同，持久性 Cookie 可以指定一个特定的过期时间（Expires）或有效期（Max-Age）。

1	Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Cookie 的 `Secure` 和 `HttpOnly` 标记

标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端。

为避免跨域脚本 (XSS) 攻击，通过 JavaScript 的 Document.cookie API无法访问带有 HttpOnly 标记的 Cookie。

Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。

1	Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Domain 和 Path 标识定义了 Cookie 的作用域：即 Cookie 应该发送给哪些 URL。

每个 Cookie 都会有与之关联的域（Domain），如果 Cookie 的域和页面的域相同，那么我们称这个 Cookie 为第一方 Cookie（first-party cookie），如果 Cookie 的域和页面的域不同，则称之为第三方 Cookie（third-party cookie.）。

通过第三方组件发送的第三方 Cookie 主要用于广告和网络追踪。

什么情况下需要 CORS ？

由 XMLHttpRequest 或 Fetch 发起的跨域 HTTP 请求
Web 字体 (CSS 中通过 @font-face 使用跨域字体资源)
WebGL 贴图
使用 drawImage 将 Images/video 画面绘制到 canvas

基本功能

跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站通过浏览器有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。

CORS 请求失败会产生错误，但是为了安全，在 JavaScript 代码层面是无法获知到底具体是哪里出了问题。只能查看浏览器的控制台以得知具体是哪里出现了错误。

若干访问控制场景

简单请求

某些请求不会触发 CORS 预检请求，这样的请求为『简单请求』。

简单请求

若请求满足所有下述条件，则该请求可视为『简单请求』：

1. 使用下列方法之一：
GET
HEAD
POST

2. Fetch 规范定义了对 CORS 安全的首部字段集合，不得人为设置该集合之外的其他首部字段。该集合为：
Accept
Accept-Language
Content-Language
Content-Type （需要注意额外的限制）
DPR
Downlink
Save-Data
Viewport-Width
Width

3. Content-Type 的值仅限于下列三者之一：
text/plain
multipart/form-data
application/x-www-form-urlencoded

4. 请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问。

5. 请求中没有使用 ReadableStream 对象。

预检请求

『需预检的请求』要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。『预检请求』的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。

预检请求

当请求满足下述任一条件时，即应首先发送预检请求：

1. 使用了下面任一 HTTP 方法：
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH

2. 人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为：
Accept
Accept-Language
Content-Language
Content-Type (需要注意额外的限制)
DPR
Downlink
Save-Data
Viewport-Width
Width

3. Content-Type 的值不属于下列之一:
application/x-www-form-urlencoded
multipart/form-data
text/plain

4. 请求中的 XMLHttpRequestUpload 对象注册了任意多个事件监听器。

5. 请求中使用了 ReadableStream 对象。

附带身份凭证的请求

对于跨域 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位，将 XMLHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies。因为这是一个简单 GET 请求，所以浏览器不会对其发起『预检请求』。但是，如果服务器端的响应中未携带 Access-Control-Allow-Credentials: true ，浏览器将不会把响应内容返回给请求的发送者。

❗️注意：附带身份凭证的请求与通配符

对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为 *。

这是因为请求的首部中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为 *，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example，则请求将成功执行。

HTTP 响应首部字段

`Access-Control-Allow-Origin`

1	Access-Control-Allow-Origin: <origin> \| *

origin 参数的值指定了允许访问该资源的外域 URI。对于不需要携带身份凭证的请求，服务器可以指定该字段的值为通配符，表示允许来自所有域的请求。

如果服务端指定了具体的域名而非 *，那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端：服务器对不同的源站返回不同的内容。

`Access-Control-Expose-Headers`

在跨域访问时，XMLHttpRequest 对象的 getResponseHeader() 方法只能拿到一些最基本的响应头，Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。

Access-Control-Expose-Headers 头让服务器把允许浏览器访问的头放入白名单，例如：

1	Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

这样浏览器就能够通过 getResponseHeader 访问 X-My-Custom-Header 和 X-Another-Custom-Header 响应头了。

`Access-Control-Max-Age`

Access-Control-Max-Age 头指定了 preflight 请求的结果能够被缓存多久

1	Access-Control-Max-Age: <delta-seconds>

`Access-Control-Allow-Credentials`

Access-Control-Allow-Credentials

`Access-Control-Allow-Methods`

Access-Control-Allow-Methods 首部字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。

1	Access-Control-Allow-Methods: <method>[, <method>]*

`Access-Control-Allow-Headers`

Access-Control-Allow-Headers 首部字段用于预检请求的响应。其指明了实际请求中允许携带的首部字段。

1	Access-Control-Allow-Headers: <field-name>[, <field-name>]*

HTTP 请求首部字段

`Origin`

Origin 首部字段表明预检请求或实际请求的源站。

1	Origin: <origin>

origin 参数的值为源站 URI。它不包含任何路径信息，只是服务器名称。

`Access-Control-Request-Method`

Access-Control-Request-Method 首部字段用于预检请求。其作用是，将实际请求所使用的 HTTP 方法告诉服务器。

Access-Control-Request-Method:

`Access-Control-Request-Headers`

Access-Control-Request-Headers 首部字段用于预检请求。其作用是，将实际请求所携带的首部字段告诉服务器。

1	Access-Control-Request-Headers: <field-name>[, <field-name>]*

HTTP Messages

HTTP报文

组成

HTTP 请求和响应具有相似的结构，由以下部分组成︰

1. 一行起始行用于描述要执行的请求，或者是对应的状态，成功或失败。这个起始行总是单行的。
2. 一个可选的 HTTP 头集合指明请求或描述消息正文。
3. 一个空行指示所有关于请求的元数据已经发送完毕。
4. 一个可选的包含请求相关数据的正文 (比如 HTML 表单内容), 或者响应相关的文档。正文的大小有起始行的 HTTP 头来指定。

起始行和 HTTP 消息中的 HTTP 头统称为请求头，而其有效负载被称为消息正文。

HTTP 请求

起始行

起始行 (start-line) 包含三个元素：

1. 一个 HTTP 方法，一个动词 (像 GET, PUT 或者 POST) 或者一个名词 (像 HEAD 或者 OPTIONS), 描述要执行的动作. 例如, GET 表示要获取资源，POST 表示向服务器推送数据 (创建或修改资源, 或者产生要返回的临时文件)。

2. 请求目标 (request target)，通常是一个 URL，或者是协议、端口和域名的绝对路径，通常以请求的环境为特征。请求的格式因不同的 HTTP 方法而异。它可以是：

一个绝对路径，末尾跟上一个 ‘ ? ‘ 和查询字符串。这是最常见的形式，称为『原始形式』(origin form)，被 GET，POST，HEAD 和 OPTIONS 方法所使用。

POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0

一个完整的 URL，被称为『绝对形式』 (absolute form)，主要在使用 GET 方法连接到代理时使用。

1	GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

由域名和可选端口（以’:’为前缀）组成的 URL 的 authority component，称为 authority form。仅在使用 CONNECT 建立 HTTP 隧道时才使用。

1	CONNECT developer.mozilla.org:80 HTTP/1.1

星号形式 (asterisk form)，一个简单的星号(*)，配合 OPTIONS 方法使用，代表整个服务器。

1	OPTIONS * HTTP/1.1

3. HTTP 版本 (HTTP version)，定义了剩余报文的结构，作为对期望的响应版本的指示符。

Headers

分类

Headers 可以分为几组：

1. General headers，例如 Via，适用于整个报文。

2. Request headers，例如 User-Agent，Accept-Type，通过进一步的定义(例如 Accept-Language)，或者给定上下文(例如 Referer)，或者进行有条件的限制 (例如 If-None) 来修改请求。

3. Entity headers，例如 Content-Length，适用于请求的 body。显然，如果请求中没有任何 body，则不会发送这样的头文件。

Body

分类

不是所有的请求都有一个 body：例如获取资源的请求，GET，HEAD，DELETE 和 OPTIONS，通常它们不需要 body。有些请求将数据发送到服务器以便更新数据：常见的的情况是 POST 请求（包含 HTML 表单数据）。

Body 大致可分为两类：

1. Single-resource bodies，由一个单文件组成。该类型 body 由两个 header 定义： Content-Type 和 Content-Length。

2. Multiple-resource bodies，由多部分 body 组成，每一部分包含不同的信息位。通常是和 HTML Forms 连系在一起。

HTTP 响应

状态行

组成

HTTP 响应的起始行被称作状态行 (status line)，包含以下信息：

1. 协议版本，通常为 HTTP/1.1。
2. 状态码 (status code)，表明请求是成功或失败。常见的状态码是 200，404 或 302。
3. 状态文本 (status text)。一个简短的信息，通过状态码的文本描述，帮助人们理解该 HTTP 消息。

一个典型的状态行看起来像这样：HTTP/1.1 404 Not Found。

Headers

Body

分类

不是所有的响应都有 body：具有状态码 (如 201 或 204) 的响应，通常不会有 body。

Body 大致可分为三类：

1. Single-resource bodies，由已知长度的单个文件组成。该类型 body 由两个 header 定义：Content-Type 和 Content-Length。

2. Single-resource bodies，由未知长度的单个文件组成，通过将 Transfer-Encoding 设置为 chunked 来使用 chunks 编码。

3. Multiple-resource bodies，由多部分 body 组成，每部分包含不同的信息段。但这是比较少见的。

HTTP/2 帧

HTTP/1.x 报文有一些性能上的缺点：

Header 不像 body，它不会被压缩。
两个报文之间的 header 通常非常相似，但它们仍然在连接中重复传输。
无法复用。当在同一个服务器打开几个连接时：TCP 热连接比冷连接更加有效。

HTTP/2 引入了一个额外的步骤：它将 HTTP/1.x 消息分成帧并嵌入到流 (stream) 中。数据帧和报头帧分离，这将允许报头压缩。将多个流组合，这是一个被称为多路复用 (multiplexing) 的过程，它允许更有效的底层 TCP 连接。

HTTP 帧现在对 Web 开发人员是透明的。在 HTTP/2 中，这是一个在 HTTP/1.1 和底层传输协议之间附加的步骤。Web 开发人员不需要在其使用的 API 中做任何更改来利用 HTTP 帧；当浏览器和服务器都可用时，HTTP/2 将被打开并使用。

HTTP Headers

Authentication

WWW-Authenticate
Defines the authentication method that should be used to gain access to a resource.

Authorization
Contains the credentials to authenticate a user agent with a server.

Proxy-Authenticate
Defines the authentication method that should be used to gain access to a resource behind a Proxy server.

Proxy-Authorization
Contains the credentials to authenticate a user agent with a proxy server.

Caching

Authentication

Age
The time in seconds the object has been in a proxy cache.

Cache-Control
Specifies directives for caching mechanisms in both requests and responses.

Clear-Site-Data
Clears browsing data (e.g. cookies, storage, cache) associated with the requesting website.

Expires
The date/time after which the response is considered stale.

Pragma
Implementation-specific header that may have various effects anywhere along the request-response chain. Used for backwards compatibility with HTTP/1.0 caches where the Cache-Control header is not yet present.

Warning
A general warning field containing information about possible problems.

Conditionals

Last-Modified
It is a validator, the last modification date of the resource, used to compare several versions of the same resource. It is less accurate than ETag, but easier to calculate in some environments. Conditional requests using If-Modified-Since and If-Unmodified-Since use this value to change the behavior of the request.

ETag
It is a validator, a unique string identifying the version of the resource. Conditional requests using If-Match and If-None-Match use this value to change the behavior of the request.

If-Match
Makes the request conditional and applies the method only if the stored resource matches one of the given ETags.

If-None-Match
Makes the request conditional and applies the method only if the stored resource doesn’t match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one is already existing.

If-Modified-Since
Makes the request conditional and expects the entity to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.

If-Unmodified-Since
Makes the request conditional and expects the entity to be transmitted only if it has not been modified after the given date. This is used to ensure the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.

Vary
Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.

Connection managementSection

Connection
Controls whether the network connection stays open after the current transaction finishes.

Keep-Alive
Controls how long a persistent connection should stay open.

Content negotiationSection

Accept
Informs the server about the types of data that can be sent back. It is MIME-type.

Accept-Charset
Informs the server about which character set the client is able to understand.

Accept-Encoding
Informs the server about the encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.

Accept-Language
Informs the server about the language the server is expected to send back. This is a hint and is not necessarily under the full control of the user: the server should always pay attention not to override an explicit user choice (like selecting a language in a drop down list).

Controls

Expect
Indicates expectations that need to be fulfilled by the server in order to properly handle the request.

Cookies

Cookie
Contains stored HTTP cookies previously sent by the server with the Set-Cookie header.

Set-Cookie
Send cookies from the server to the user agent.

CORS

Access-Control-Allow-Origin
Indicates whether the response can be shared.

Access-Control-Allow-Credentials
Indicates whether the response to the request can be exposed when the credentials flag is true.

Access-Control-Allow-Headers
Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.

Access-Control-Allow-Methods
Specifies the method or methods allowed when accessing the resource in response to a preflight request.

Access-Control-Expose-Headers
Indicates which headers can be exposed as part of the response by listing their names.

Access-Control-Max-Age
Indicates how long the results of a preflight request can be cached.

Access-Control-Request-Headers
Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.

Access-Control-Request-Method
Used when issuing a preflight request to let the server know which HTTP method will be used when the actual request is made.

Origin
Indicates where a fetch originates from.

Timing-Allow-Origin
Specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions.

Do Not TrackSection

DNT
Used for expressing the user’s tracking preference.

Tk
Indicates the tracking status that applied to the corresponding request.

Downloads

Do Not TrackSection

Content-Disposition
Is a response header if the resource transmitted should be displayed inline (default behavior when the header is not present), or it should be handled like a download and the browser should present a ‘Save As’ window.

Message body information

Content-Length
Indicates the size of the entity-body, in decimal number of octets, sent to the recipient.

Content-Type
Indicates the media type of the resource.

Content-Encoding
Used to specify the compression algorithm.

Content-Language
Describes the language(s) intended for the audience, so that it allows a user to differentiate according to the users’ own preferred language.

Content-Location
Indicates an alternate location for the returned data.

Proxies

Forwarded
Contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request.

Via
Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.

Redirects

Location
Indicates the URL to redirect a page to.

Request context

From
Contains an Internet email address for a human user who controls the requesting user agent.

Host
Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.

Referer
The address of the previous web page from which a link to the currently requested page was followed.

Referrer-Policy
Governs which referrer information sent in the Referer header should be included with requests made.

User-Agent
Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent.

Response context

Allow
Lists the set of HTTP request methods support by a resource.

Server
Contains information about the software used by the origin server to handle the request.

Range requests

Accept-Ranges
Indicates if the server supports range requests, and if so in which unit the range can be expressed.

Range
Indicates the part of a document that the server should return.

If-Range
Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.

Content-Range
Indicates where in a full body message a partial message belongs.

HTTP 的重定向

Redirections in HTTP

URL 重定向，也称为 URL 转发，是一种当实际资源，如单个页面、表单或者整个 Web 应用被迁移到新的 URL 下的时候，保持（原有）链接可用的技术。HTTP 协议提供了一种特殊形式的响应—— HTTP 重定向（HTTP redirects）来执行此类操作，该操作可以应用于多种多样的目标：网站维护期间的临时跳转，网站架构改变后为了保持外部链接继续可用的永久重定向，上传文件时的表示进度的页面，等等。

原理

在 HTTP 协议中，重定向操作由服务器通过发送特殊的响应（即 redirects）而触发。HTTP 协议的重定向响应的状态码为 3xx 。浏览器在接收到重定向响应的时候，会采用该响应提供的新的 URL ，并立即进行加载；大多数情况下，除了会有一小部分性能损失之外，重定向操作对于用户来说是不可见的。

不同类型的重定向映射可以划分为三个类别：永久重定向、临时重定向和特殊重定向。

永久重定向

表示原 URL 不应再被使用，而应该优先选用新的 URL。

301、308

临时重定向

有时候请求的资源无法从其标准地址访问，但是却可以从另外的地方访问。在创建、更新或者删除资源的时候，临时重定向也可以用于显示临时性的进度页面。

302、303、307

特殊重定向

304（Not Modified，资源未被修改）会使页面跳转到本地陈旧的缓存版本当中，而 300（Multiple Choice，多项选择）则是一种手工重定向：以 Web 页面形式呈现在浏览器中的消息主体包含了一个可能的重定向链接的列表，用户可以从中进行选择。

设定重定向映射的其他方法

HTML 重定向机制

1
2
3

<head> 
  <meta http-equiv="refresh" content="0;URL=http://www.example.com/" />
</head>

JavaScript 重定向机制

1	window.location = "http://www.example.com/";

优先级

HTTP
HTML
JavaScript

应用场景

需要注意应该尽可能地限制其使用数量，因为每一次重定向都会带来性能上的开销。

域名别称

保持链接有效

对于不安全请求的临时响应

对于耗时请求的临时响应

在通用服务器中配置重定向

Nginx

创建一个服务器模块来进行重定向设置：

server {
	listen 80;
	server_name example.com;
	return 301 $scheme://www.example.com$request_uri;
}

使用 rewrite 指令来针对一个文件目录或者一部分页面应用重定向设置：

1 2	rewrite ^/images/(.)$ http://images.example.com/$1 redirect; rewrite ^/images/(.)$ http://images.example.com/$1 permanent;

重定向死锁（循环）

HTTP Request Methods

HTTP request methods

`GET`

The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.

`HEAD`

The HEAD method asks for a response identical to that of a GET request, but without the response body.

`POST`

The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.

`PUT`

The PUT method replaces all current representations of the target resource with the request payload.

`DELETE`

The DELETE method deletes the specified resource.

`CONNECT`

The CONNECT method establishes a tunnel to the server identified by the target resource.

`OPTIONS`

The OPTIONS method is used to describe the communication options for the target resource.

`TRACE`

The TRACE method performs a message loop-back test along the path to the target resource.

`PATCH`

The PATCH method is used to apply partial modifications to a resource.

HTTP Status Response Codes

HTTP response status codes

HTTP 状态码

状态码为客户端提供了一种理解事物处理结果的便捷方式。

总的来说，可以将HTTP状态码分为五类：

以1开头的信息性状态码；
以2开头的成功状态码；
以3开头的重定向状态码；
以4开头的客户端错误状态码；
以5开头的服务器错误状态码；

CSP directives

Content-Security-Policy

HTTP 响应头 Content-Security-Policy 允许站点管理者控制用户代理能够为指定的页面加载哪些资源。除了少数例外情况，设置的政策主要涉及指定服务器的源和脚本结束点。这将帮助防止跨站脚本攻击（Cross-Site Script）

A typical HTTP session

Connection management in HTTP/1.x

HTTP 2

HTTP/2

What is HTTP/2?

HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.

The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.

Overview of HTTP

HTTP Cache

缓存控制

Cache-control

Pragma

新鲜度

定义最佳 Cache-Control 策略

缓存验证

带 Vary 头的响应

HTTP Cookies

用途

创建 Cookie

Set-Cookie 响应头部和 Cookie 请求头部

会话期 Cookie

持久性 Cookie

Cookie 的 Secure 和 HttpOnly 标记

Cookie 的作用域

第三方 Cookie

相关链接

Cross-Origin Resource Sharing (CORS)

什么情况下需要 CORS ？

基本功能

若干访问控制场景

简单请求

预检请求

附带身份凭证的请求

❗️注意：附带身份凭证的请求与通配符

HTTP 响应首部字段

Access-Control-Allow-Origin

Access-Control-Expose-Headers

Access-Control-Max-Age

Access-Control-Allow-Credentials

Access-Control-Allow-Methods

Access-Control-Allow-Headers

HTTP 请求首部字段

Origin

Access-Control-Request-Method

Access-Control-Request-Headers

HTTP Messages

HTTP 请求

起始行

Headers

Body

HTTP 响应

状态行

Headers

Body

HTTP/2 帧

HTTP Headers

Authentication

Caching

Conditionals

Connection managementSection

Content negotiationSection

Controls

Cookies

CORS

Do Not TrackSection

Downloads

Message body information

Proxies

Redirects

Request context

Response context

Range requests

HTTP 的重定向

原理

永久重定向

临时重定向

特殊重定向

设定重定向映射的其他方法

HTML 重定向机制

JavaScript 重定向机制

优先级

应用场景

域名别称

保持链接有效

对于不安全请求的临时响应

对于耗时请求的临时响应

在通用服务器中配置重定向

`Cache-control`

`Pragma`

`Set-Cookie` 响应头部和 `Cookie` 请求头部

Cookie 的 `Secure` 和 `HttpOnly` 标记

`Access-Control-Allow-Origin`

`Access-Control-Expose-Headers`

`Access-Control-Max-Age`

`Access-Control-Allow-Credentials`

`Access-Control-Allow-Methods`

`Access-Control-Allow-Headers`

`Origin`

`Access-Control-Request-Method`

`Access-Control-Request-Headers`

`GET`

`HEAD`

`POST`

`PUT`

`DELETE`

`CONNECT`

`OPTIONS`

`TRACE`

`PATCH`