recursal/MDN huggingface dataset:
background\_color
=================

**实验性:** **这是一项实验性技术**  
在将其用于生产之前，请仔细检查浏览器兼容性表格。

|  |  |
| --- | --- |
| 类型 | `String` |
| 强制 | 否 |

`background_color` 成员为应用程序页面定义了一个占位背景颜色，以便在其样式表加载之前显示。当清单在样式表加载前可用时，用户代理会使用这个值来绘制快捷方式的背景颜色。

因此，`background_color` 应与 `background-color` 网站样式表中的 CSS 属性匹配，以在启动 Web 应用程序和加载网站内容之间进行平滑过渡。

**备注：** 该 `background_color` 成员仅用于在从网络或存储介质加载主样式表时改善用户体验。当渐进式 Web 应用程序样式表可用时，用户代理不会将 `background-color` 用作 CSS 属性。

实例
--


```json
"background\_color": "red"
```

规范
--

| Specification |
| --- |
| Web Application Manifest # background\_color-member |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
Proxy servers and tunneling
===========================

当访问不同的网站时，代理服务器和 HTTP 管道帮助访问万维网 . 一个代理可以是用户的本地计算机，或者介于用户计算机和终端服务器之间的地方。本章节概述一些关于代理和相关配置选项的基础知识。

有两种代理：**正向代理** (如：管道、网关) 和**反向代理** (用于控制和保证服务器的负载均衡、认证、加密和缓存)。

正向代理
----

正向代理，也可以叫“网关”或者仅仅为一个或多个客户端提供代理服务的“代理”。在互联网上像这样的代理不计其数。他们存储并转发网络服务（如 DNS，网页）以减少和控制大家所使用的带宽。

正向代理可以是匿名代理，并允许用户在浏览 web 或者使用其他服务时隐藏自己的 IP。 TOR (洋葱路由), 匿名地在多个代理间路由因特网。

反向代理
----

顾名思义，反向代理所做的事情与正向代理相反：正向代理代表客户端（或者发送请求的主机），而反向代理代表服务器。正向代理可以隐藏客户端的身份，而反向代理可以隐藏服务器的身份。反向代理的用处很多，例如：

* 负载均衡：在多个服务器之间分发负载，
* 缓存静态内容：缓存图片等静态内容，为服务器分担压力，
* 压缩：压缩和优化内容以加快传输的速度。
通过代理转发客户端消息
-----------

代理可以将请求地址设置为自身的 IP，这可以隐匿客户端的身份。然而，这也会导致原始请求的部分信息丢失。发起请求的客户端的 IP 地址可以用来调试、统计或者生成基于位置的内容。通常使用如下 HTTP 头来暴露这部分信息：

标准头部：

`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.

Or the de-facto standard versions:

`X-Forwarded-For` 
非标准

Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.

`X-Forwarded-Host` 
非标准

Identifies the original host requested that a client used to connect to your proxy or load balancer.

`X-Forwarded-Proto` 
非标准

identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.

To provide information about the proxy itself (not about the client connecting to it), the `Via` header can be used.

`Via`

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

HTTP tunneling
--------------

Tunneling transmits private network data and protocol information through public network by encapsulating the data. HTTP tunneling is using a protocol of higher level (HTTP) to transport a lower level protocol (TCP).

The HTTP protocol specifies a request method called `CONNECT`. It starts two-way communications with the requested resource and can be used to open a tunnel. This is how a client behind an HTTP proxy can access websites using SSL (i.e. HTTPS, port 443). Note, however, that not all proxy servers support the `CONNECT` method or limit it to port 443 only.

See also the HTTP tunnel article on Wikipedia.

Proxy Auto-Configuration (PAC)
------------------------------

A Proxy Auto-Configuration (PAC) file is a JavaScript function that determines whether web browser requests (HTTP, HTTPS, and FTP) go directly to the destination or are forwarded to a web proxy server. The JavaScript function contained in the PAC file defines the function:

The auto-config file should be saved to a file with a `.pac` filename extension:
```

proxy.pac
```


And the MIME type set to:
```

application/x-ns-proxy-autoconfig
```


The file consists of a function called `FindProxyForURL`. The example below will work in an environment where the internal DNS server is set up so that it can only resolve internal host names, and the goal is to use a proxy only for hosts that aren't resolvable:


```js
function FindProxyForURL(url, host) {
  if (isResolvable(host)) return "DIRECT";
  else return "PROXY proxy.mydomain.com:8080";
}
```


参见代理自动配置（PAC）以获取更多示例。

参见
--

* `CONNECT`
* 维基百科上的代理服务器
Resources and URIs
==================

HTTP 允许浏览器或用户代理与互联网上的不同*资源*进行通信。要做到这一点，需要知道资源的*身份*与*位置*。这两部分的信息用URI来定义。

定位网络资源

URI 与其如何访问网络资源。

数据 URI

一类特殊的 URI：数据 URI。其将数据嵌入标识符。

选择“www”URI 或“非 www”URI

有关是否使用以“www”为前缀的域名的建议。这篇文章解释了相关的结果以及其如何实现。

MIME 类型

MIME 媒体类型定义了资源是什么类型的文档。这篇文章展示了其格式与常用的 Web MIME 类型。

MIME 类型的完整列表

Web 开发人员常用的 MIME 类型列表。

分离身份与位置信息：Alt-Svc 头部

即便是使用了URI来描述身份与位置信息，其仍然是不同的两个概念。有时明确的进行区分非常必要。这篇文章介绍了Alt-Svc。
HTTP 请求范围
=========

HTTP 协议范围请求允许服务器只发送 HTTP 消息的一部分到客户端。范围请求在传送大的媒体文件，或者与文件下载的断点续传功能搭配使用时非常有用。

检测服务器端是否支持范围请求
--------------

假如在响应中存在 `Accept-Ranges` 首部（并且它的值不为“none”），那么表示该服务器支持范围请求。例如，你可以使用 cURL 发送一个 `HEAD` 请求来进行检测。
```

curl -I http://i.imgur.com/z4d4kWk.jpg

HTTP/1.1 200 OK
...
Accept-Ranges: bytes
Content-Length: 146515
```


在上面的响应中， `Accept-Ranges: bytes` 表示界定范围的单位是 bytes。这里 `Content-Length` 也是有效信息，因为它提供了要检索的图片的完整大小。

如果站点未发送 `Accept-Ranges` 首部，那么它们有可能不支持范围请求。一些站点会明确将其值设置为 "none"，以此来表明不支持。在这种情况下，某些应用的下载管理器会将暂停按钮禁用。
```

curl -I https://www.youtube.com/watch?v=EwTZ2xpQwpA

HTTP/1.1 200 OK
...
Accept-Ranges: none
```

从服务器端请求特定的范围
------------

假如服务器支持范围请求的话，你可以使用 `Range` 首部来生成该类请求。该首部指示服务器应该返回文件的哪一或哪几部分。

### 单一范围

我们可以请求资源的某一部分。这次我们依然用 cURL 来进行测试。"-H" 选项可以在请求中追加一个首部行，在这个例子中，是用 Range 首部来请求图片文件的前 1024 个字节。
```

curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"
```


这样生成的请求如下：
```

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023
```


服务器端会返回状态码为 `206` `Partial Content` 的响应：
```

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024
...
(binary content)
```


在这里，`Content-Length` 首部现在用来表示先前请求范围的大小（而不是整张图片的大小）。`Content-Range` 响应首部则表示这一部分内容在整个资源中所处的位置。

### 多重范围

Range 头部也支持一次请求文档的多个部分。请求范围用一个逗号分隔开。
```

curl http://www.example.com -i -H "Range: bytes=0-50, 100-150"
```


服务器返回 206 Partial Content 状态码和 Content-Type：multipart/byteranges; boundary=3d6b6a416f9b5 头部，Content-Type：multipart/byteranges 表示这个响应有多个 byterange。每一部分 byterange 都有他自己的 Content-type 头部和 Content-Range，并且使用 boundary 参数对 body 进行划分。
```

HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 282

--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 0-50/1270

<!doctype html>
<html>
<head>
    <title>Example Do
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-150/1270

eta http-equiv="Content-type" content="text/html; c
--3d6b6a416f9b5--
```

### 条件式范围请求

当（中断之后）重新开始请求更多资源片段的时候，必须确保自从上一个片段被接收之后该资源没有进行过修改。

The `If-Range` 请求首部可以用来生成条件式范围请求：假如条件满足的话，条件请求就会生效，服务器会返回状态码为 `206` `Partial` 的响应，以及相应的消息主体。假如条件未能得到满足，那么就会返回状态码为 `200` `OK` 的响应，同时返回整个资源。该首部可以与 `Last-Modified` 验证器或者 `ETag` 一起使用，但是二者不能同时使用。
```

If-Range: Wed, 21 Oct 2015 07:28:00 GMT
```

范围请求的响应
-------

与范围请求相关的有三种状态：

* 在请求成功的情况下，服务器会返回 `206` `Partial Content` 状态码。
* 在请求的范围越界的情况下（范围值超过了资源的大小），服务器会返回 `416` `Requested Range Not Satisfiable` （请求的范围无法满足）状态码。
* 在不支持范围请求的情况下，服务器会返回 `200` `OK` 状态码。
与分块传输编码的对比
----------

`Transfer-Encoding` 首部允许分块编码，这在数据量很大，并且在请求未能完全处理完成之前无法知晓响应的体积大小的情况下非常有用。服务器会直接把数据发送给客户端而无需进行缓冲或确定响应的精确大小——后者会增加延迟。范围请求与分块传输是兼容的，可以单独或搭配使用。

相关内容
----

* 相关状态码： `200`, `206`, `416`.
* 相关首部： `Accept-Ranges`, `Range`, `Content-Range`, `If-Range`, `Transfer-Encoding`.
* IE 浏览器中的断点续传功能
HTTP 基础
=======

HTTP 是一个拓展性非常好的协议。它依赖于资源或统一资源定位符（URI）的概念、一个简单的消息结构和一个客户端——服务器结构的通信流。在这些基础概念之上，近年来已经出现了许多拓展，以增加新的 HTTP 方法或首部的方式为 HTTP 协议增加了新的功能和语义。

文章
--

HTTP 概览

描述了什么是 HTTP，它在 Web 架构中的角色，以及它在协议栈中的位置。

HTTP 演变

HTTP 是在 20 世纪 90 年代早期出现的，并且已经被扩充了多次。本文会回顾 HTTP 的发展史，描述 HTTP/0.9、HTTP/1.0、HTTP/1.1 和最新的 HTTP/2，以及这些年来出现的一些新特性。

资源和 URI

简单介绍了资源，标示符和 Web 位置的概念。

辨别 Web 资源

描述了 Web 资源是怎样被引用和找到的。

数据 URL

一种特殊的 URI，它直接包含了资源的内容。数据 URL 使用起来非常方便，但也有一些弊端。

资源 URL (en-US) 
非标准

资源 URL（以 `resource` 前缀）是被 Firefox 和 Firefox 浏览器拓展插件用来内在地加载资源，当然有些资源在浏览器连接的网站上存在的。

MIME 类型

从 HTTP/1.0 开始，HTTP 协议允许传输不同类型的内容。本文解释了如何通过使用 `Content-Type` 首部和 MIME 标准实现这一过程的。

在 www 和非 www URL 间选择

在是否使用 www 前缀的域名这一问题上，本文解释了不同选择的影响，并给出了具体的实施方法。

HTTP 会话流程

本文描述了一个经典的 HTTP 会话：当你在浏览器中点击一个链接或在网页中加载一张图片时，背后到底发生了什么。

HTTP 消息

在请求和响应中传输的 HTTP 消息具有非常清晰的结构；本文介绍了消息的结构、设计目的以及其可能性。

HTTP/2 中的帧及消息结构

HTTP/2 用二进制帧来压缩和表示 HTTP/1.x 中的消息。本文解释了 HTTP/2 中的帧结构，其设计目的以及编码方式。

HTTP/1.x 的连接管理

HTTP/1.1 是首个支持持久化连接和管道化的 HTTP 版本。本文介绍了这两个概念。

HTTP/2 的连接管理

HTTP/2 完全改变了连接创建和维护的方式：本文介绍了 HTTP 帧是怎样支持多路复用并解决之前的 HTTP 版本中存在的队头阻塞问题的。

内容协商

HTTP 引入了一组以 `Accept` 开头的首部，作为浏览器用来声明它们期望得到的格式，语言或编码的方法。本文讲述了这一过程是怎样实现的，以及服务器是怎样处理并选择恰当的响应的。
HTTP 资源与规范
==========

HTTP 协议于 20 世纪 90 年代初期被规范化。得益于其扩展性，该规范至今又添加了大量的补充内容。这些增补规范文档散落在网络的不同位置。本文列出了与 HTTP 协议相关的规范文档。

| 规范 | 标题 | 状态 |
| --- | --- | --- |
| RFC 7230 | 超文本传输协议（HTTP/1.1）：报文格式与路由 | 建议标准 |
| RFC 7231 | 超文本传输协议（HTTP/1.1）：语义与内容 | 建议标准 |
| RFC 7232 | 超文本传输协议（HTTP/1.1）：条件请求 | 建议标准 |
| RFC 7233 | 超文本传输协议（HTTP/1.1）：范围请求 | 建议标准 |
| RFC 7234 | 超文本传输协议（HTTP/1.1）：缓存 | 建议标准 |
| RFC 5861 | 针对陈旧内容的 HTTP 缓存控制扩展 | 信息参考 |
| RFC 8246 | 不可变的 HTTP 响应 | 建议标准 |
| RFC 7235 | 超文本传输协议（HTTP/1.1）：认证 | 建议标准 |
| RFC 6265 | HTTP 状态控制机制：定义 Cookies | 建议标准 |
| Draft spec | Cookie 前缀 | IETF 草案 |
| Draft spec | 同源 Cookies | IETF 草案 |
| Draft spec | 反对非安全的源站对安全 cookies 进行修改 | IETF 草案 |
| RFC 2145 | HTTP 版本号的使用与解释 | 信息参考 |
| RFC 6585 | 扩展的 HTTP 状态码 | 建议标准 |
| RFC 7538 | 超文本传输协议的 308 状态码（永久重定向） | 建议标准 |
| RFC 7725 | 用于报告法律限制的 HTTP 状态码 | 即将成为标准 |
| RFC 2397 | URL 的“data“方案 | 建议标准 |
| RFC 3986 | 统一资源定位符（URI）：通用语法 | 因特网标准 |
| RFC 5988 | 网络链接 *定义了 `Link` 首部字段* | 建议标准 |
| Experimental spec | 超文本传输协议（HTTP)）的 Keep-Alive 首部字段 | 信息参考（已过期） |
| Draft spec | HTTP 客户端提示 | IETF 草案 |
| RFC 7578 | 从表单中返回数据：multipart/form-data | 建议标准 |
| RFC 6266 | 在超文本传输协议（HTTP）中使用 Content-Disposition 首部字段 | 建议标准 |
| RFC 2183 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field *Only a subset of syntax of the `Content-Disposition` header can be used in the context of HTTP messages.* | 建议标准 |
| RFC 7239 | 前向 HTTP 扩展 | 建议标准 |
| RFC 6455 | WebSocket 协议 | 建议标准 |
| RFC 5246 | 安全传输层（TLS）协议 1.2 版本 *该规范已经被后续 RFC 文档进行了修改，不过这些修改不会对 HTTP 协议本身产生效力。* | 建议标准 |
| Draft spec | 安全传输层（TLS）协议 1.3 版本 *该版本就绪之后，将取代之前的 1.2 版本* | IETF 草案 |
| RFC 2817 | 在 HTTP/1.1 中进行 TLS 升级 | 建议标准 |
| RFC 7540 | 超文本传输协议版本 2（HTTP/2） | 建议标准 |
| RFC 7541 | HPACK：对 HTTP/2 的首部进行压缩 | 即将成为标准 |
| RFC 7838 | HTTP 替代服务 | 即将成为标准 |
| RFC 7301 | 对安全传输层（TLS）的应用层协议的协商的扩展 *用于在传输 HTTP/2 报文时进行协商，以减少一对额外的请求／响应* | 建议标准 |
| RFC 6454 | 网络源站的概念 | 建议标准 |
| Fetch | 跨源资源共享 | 实时标准 |
| RFC 7034 | HTTP 首部字段 X-Frame-Options | 信息参考 |
| RFC 6797 | HTTP 严格安全传输（HSTS） | 建议标准 |
| Upgrade Insecure Requests | 对不安全的请求进行升级 | 推荐候选 |
| Content Security Policy 1.0 | 内容安全策略 1.0 版本。*CSP 1.1 与 CSP 3.0 并未扩展 HTTP 协议标准* | 已废弃 |
| Microsoft document | *指定传统文档模式定义 X-UA-Compatible 规范* | 注记 |
| RFC 5689 | HTTP 拓展之 Web 分布式创作与版本控制 (WebDAV) *这些 Web 上的拓展，与 CardDAV 和 CalDAV 一起超出了 Web 上的 HTTP 的范围。当下应用的现代 API 使用了 RESTful 的接口。* | 建议标准 |
| RFC 2324 | 超文本咖啡壶控制协议（HTCPCP/1.0） | 愚人节玩笑 |
| RFC 7168 | 超文本咖啡壶控制协议的茶壶扩展（HTCPCP-TEA） | 愚人节玩笑 |
| HTML Living Standard | HTML。*针对服务端发送的事件定义了 HTTP 扩展* | 实时标准 |
| Tracking Preference Expression | DNT 首部字段 | 编辑草案／推荐候选 |
| Reporting API | `Report-To` 首部字段 | 草案 |
| Draft spec | Expect-CT 拓展于 HTTP | IETF 草案 |
HTTP 协议中的数据压缩
=============

**数据压缩**是提高 Web 站点性能的一种重要手段。对于有些文件来说，高达 70% 的压缩比率可以大大减低对于带宽的需求。随着时间的推移，压缩算法的效率也越来越高，同时也有新的压缩算法被发明出来，应用在客户端与服务器端。

在实际应用时，web 开发者不需要亲手实现压缩机制，浏览器及服务器都已经将其实现了，不过他们需要确保在服务器端进行了合理的配置。数据压缩会在三个不同的层面发挥作用：

* 首先某些格式的文件会采用特定的优化算法进行压缩，
* 其次在 HTTP 协议层面会进行通用数据加密，即数据资源会以压缩的形式进行端到端传输，
* 最后数据压缩还会发生在网络连接层面，即发生在 HTTP 连接的两个节点之间。
文件格式压缩
------

每一种文件类型都会存有冗余，也就是*浪费的空间*。如果一个典型的文本文件存在 60% 的冗余的话，那么对于其他类型的文件，例如音频或视频文件来说，这个比率会更高。不同于文本文件，这些其他类型的媒体文件占据的空间也更大，所以很早就出现了回收这些浪费的空间的需求。工程师们设计了可以应用于特定用途的文件类型的经过优化的算法。用于文件的压缩算法可以大致分为两类：

* *无损压缩*。在压缩与解压缩的循环期间，不会对要恢复的数据进行修改。复原后的数据与原始数据是一致的（比特与比特之间一一对应）。对于图片文件来说，`gif` 或者 `png` 格式的文件就是采用了无损压缩算法。
* *有损压缩*。在压缩与解压缩的循环期间，会对原始数据进行修改，但是会（希望）以用户无法觉察的方式进行。网络上的视频文件通常采用有损压缩算法，`jpeg` 格式的图片也是有损压缩。

一些特定的文件格式既可以采用无损压缩算法，又可以采用有损压缩算法，例如 `webp`，并且有损压缩算法可以对压缩比率进行配置，当然这会导致压缩品质的不同。为了使一个站点获得更好的性能，理想情况是在保持可以接受的品质水准的前提下，压缩比率尽可能得高。对于图片来说，通过压缩工具生成的图片对于 Web 应用来说，优化程度可能依然不够高。一般建议选用在保持所要求的品质的前提下压缩比率尽可能高的工具。这里有各种各样的工具专门用来干这个。

有损压缩通常会比无损压缩效率更高一些。

**备注：** 由于数据压缩技术在一些特定类型的文件上效果很好，再次进行压缩通常没有什么效果。事实上，这种做法常常会适得其反，因为间接开销（该类型算法通常需要使用字典，而字典的大小是会计入初始大小的）会比在压缩过程中获取的额外收益要高，从而会使文件的体积增加。不要对压缩格式的文件应用如下两种压缩技术。

端到端压缩技术
-------

对于各种压缩手段来说，端到端压缩技术是 Web 站点性能提升最大的地方。端到端压缩技术指的是消息主体的压缩是在服务器端完成的，并且在传输过程中保持不变，直到抵达客户端。不管途中遇到什么样的中间节点，它们都会使消息主体保持原样。

![服务器通过网络节点向客户端发送一个压缩的 HTTP 主体。该主体直到到达客户端之前，不会在网络中的任何一跳之间进行解压缩。](/zh-CN/docs/Web/HTTP/Compression/httpenco1.png)

所有的现代浏览器及服务器都支持该技术，唯一需要协商的是所采用的压缩算法。这些压缩算法是为文本内容进行过优化的。在上世纪 90 年代，压缩技术快速发展，为数众多的算法相继出现，扩大了可选的范围。如今只有两种算法有着举足轻重的地位：`gzip` 应用最广泛，`br` 则是新的挑战者。

为了选择要采用的压缩算法，浏览器和服务器之间会使用主动协商机制。浏览器发送 `Accept-Encoding` 标头，其中包含有它所支持的压缩算法，以及各自的优先级，服务器则从中选择一种，使用该算法对响应的消息主体进行压缩，并且发送 `Content-Encoding` 标头来告知浏览器它选择了哪一种算法。由于该内容协商过程是基于编码类型来选择资源的展现形式的，在响应时，服务器至少发送一个包含 `Accept-Encoding` 的 `Vary` 标头以及该标头；这样的话，缓存服务器就可以对资源的不同展现形式进行缓存。

![客户端使用“Accept-Encoding:br, gzip”标头请求内容。服务器使用 Brotli 算法压缩的主体以及所需的“Content-Encoding”和“Vary”标头进行响应。](/zh-CN/docs/Web/HTTP/Compression/httpcompression1.png)

由于压缩技术可以带来很大的性能提升，建议对除了已经经过压缩的文件如图片、音频和视频文件之外的其他类型的文件均进行压缩。

Apache 服务器支持数据压缩，有 mod\_deflate可供使用；nginx 中有ngx\_http\_gzip\_module 模块；在 IIS 中则可以使用 `<httpCompression>` 元素。

逐跳压缩技术
------

逐跳压缩技术尽管与端到端压缩技术有些类似，但是它们在一点上有着本质的区别：即这里的压缩指的不是对源头服务器上的资源的压缩，以此来创建一份特定的展现形式然后进行传输，而是对客户端与服务器端之间的任意两个节点之间传递的消息的主体的压缩。在两个相邻的中间节点之间的连接上，可能会应用*不同*的压缩方式。

![服务器通过网络节点向客户端发送一个未经压缩的 HTTP 主体。该主体在到达客户端之前，由网络上的节点根据“Transfer-Encoding”标头进行压缩和解压缩。](/zh-CN/docs/Web/HTTP/Compression/httpte1.png)

为了实现这个目的，HTTP 协议中采用了与端到端压缩技术所使用的内容协商机制相类似的机制：节点发送请求，使用 `TE` 标头来宣告它的意愿，另外一个节点则从中选择合适的方法，进行应用，然后在 `Transfer-Encoding` 标头中指出它所选择的方法。

![客户端从没有压缩相关标头的服务器请求内容。服务器会使用未经压缩的主体进行响应。该主体在到达客户端之前，由网络上的节点进行压缩和解压缩。](/zh-CN/docs/Web/HTTP/Compression/httpcomp2.png)

在实际应用中，逐跳压缩对于服务器和客户端来说是不可见的，并且很少使用。`TE` 标头和 `Transfer-Encoding` 标头最常用来发送分块响应，允许在获得资源的确切长度之前就可以开始传输。

注意，在单次转发层面使用 `Transfer-Encoding` 标头和压缩技术是如此地少见，以至于 Apache、nginx 或 IIS 等服务器都不太容易配置。此类配置通常用在代理服务器层面。
HTTP 请求方法
=========

HTTP 定义了一组**请求方法**，以表明要对给定资源执行的操作。指示针对给定资源要执行的期望动作。虽然它们也可以是名词，但这些请求方法有时被称为 *HTTP 动词*。每一个请求方法都实现了不同的语义，但一些共同的特征由一组共享：例如一个请求方法可以是安全的、幂等的或可缓存的。

`GET`

`GET` 方法请求一个指定资源的表示形式，使用 `GET` 的请求应该只被用于获取数据。

`HEAD`

`HEAD` 方法请求一个与 `GET` 请求的响应相同的响应，但没有响应体。

`POST`

`POST` 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用。

`PUT`

`PUT` 方法用有效载荷请求替换目标资源的所有当前表示。

`DELETE`

`DELETE` 方法删除指定的资源。

`CONNECT`

`CONNECT` 方法建立一个到由目标资源标识的服务器的隧道。

`OPTIONS`

`OPTIONS` 方法用于描述目标资源的通信选项。

`TRACE`

`TRACE` 方法沿着到目标资源的路径执行一个消息环回测试。

`PATCH`

`PATCH` 方法用于对资源应用部分修改。

规范
--

| Specification |
| --- |
| HTTP Semantics # CONNECT |
| HTTP Semantics # DELETE |
| HTTP Semantics # GET |
| HTTP Semantics # HEAD |
| HTTP Semantics # OPTIONS |
| HTTP Semantics # POST |
| HTTP Semantics # PUT |
| HTTP Semantics # TRACE |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

参见
--

* HTTP 标头
Cross-Origin-Embedder-Policy
============================

HTTP **`Cross-Origin-Embedder-Policy`** (COEP) 响应标头可防止文档加载未明确授予文档权限 (通过 CORP (en-US) 或者 CORS) 的任何跨域资源。

| Header type | Response header |
| --- | --- |
| Forbidden header name | no |

语法
--
```

Cross-Origin-Embedder-Policy: unsafe-none | require-corp
```

### 指令

`unsafe-none`

这是默认值。允许文档获取跨源资源，而无需通过 CORS 协议或 `Cross-Origin-Resource-Policy` 头。

`require-corp`

 文档只能从相同的源加载资源，或显式标记为可从另一个源加载的资源。
 如果跨源资源支持 CORS，则 `crossorigin` 属性或 `Cross-Origin-Resource-Policy` 头必须使用它来加载资源，而不会被 COEP 阻止。


示例
--

### 某些功能取决于跨域隔离

为了节省时间你可以只接受类似于`SharedArrayBuffer` 或者 `Performance.now()` 对象，只要你的文档有一个值被设置为`require-corp` 的 COEP 头部。
```

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
```


你可以看看这个头部 `Cross-Origin-Opener-Policy` (en-US) ，这样你设置起来会做的更好。

检查 cross origin isolation 是否成功，你可以再次测试`crossOriginIsolated` 这个属性 是否对窗口和工作的上下文有效：


```js
if (crossOriginIsolated) {
  // Post SharedArrayBuffer
} else {
  // Do something else
}
```

### 避免 CORS 阻塞 COEP

If you enable COEP using `require-corp` and have a cross origin resource that needs to be loaded, it needs to support CORS and you need to explicitly mark the resource as loadable from another origin to avoid blockage from COEP. For example, you can use the `crossorigin` attribute for this image from a third-party site:


```html
<img src="https://thirdparty.com/img.png" crossorigin />
```

规范
--

| Specification |
| --- |
| HTML Standard # coep |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

参阅
--

* `Cross-Origin-Opener-Policy` (en-US)
If-None-Match
=============

**`If-None-Match`** 是一个条件式请求首部。对于 GET`GET` 和 `HEAD` 请求方法来说，当且仅当服务器上没有任何资源的 `ETag` 属性值与这个首部中列出的相匹配的时候，服务器端才会返回所请求的资源，响应码为 `200` 。对于其他方法来说，当且仅当最终确认没有已存在的资源的 `ETag` 属性值与这个首部中所列出的相匹配的时候，才会对请求进行相应的处理。

对于 `GET` 和 `HEAD` 方法来说，当验证失败的时候，服务器端必须返回响应码 304（Not Modified，未改变）。对于能够引发服务器状态改变的方法，则返回 412（Precondition Failed，前置条件失败）。需要注意的是，服务器端在生成状态码为 304 的响应的时候，必须同时生成以下会存在于对应的 200 响应中的首部：Cache-Control、Content-Location、Date、ETag、Expires 和 Vary。

`ETag` 属性之间的比较采用的是**弱比较算法**，即两个文件除了每个字节都相同外，内容一致也可以认为是相同的。例如，如果两个页面仅仅在页脚的生成时间有所不同，就可以认为二者是相同的。

当与 `If-Modified-Since` 一同使用的时候，If-None-Match 优先级更高（假如服务器支持的话）。

以下是两个常见的应用场景：

* 采用 `GET` 或 `HEAD` 方法，来更新拥有特定的`ETag` 属性值的缓存。
* 采用其他方法，尤其是 `PUT`，将 `If-None-Match` used 的值设置为 \* ，用来生成事先并不知道是否存在的文件，可以确保先前并没有进行过类似的上传操作，防止之前操作数据的丢失。这个问题属于更新丢失问题的一种。

| Header type | Request header |
| --- | --- |
| Forbidden header name | no |

语法
--
```

If-None-Match: <etag_value>
If-None-Match: <etag_value>, <etag_value>, …
If-None-Match: *
```

指令
--

<etag\_value>

唯一地表示所请求资源的实体标签。形式是采用双引号括起来的由 ASCII 字符串（如"675af34563dc-tr34"），有可能包含一个 W/ 前缀，来提示应该采用弱比较算法（这个是画蛇添足，因为 If-None-Match 用且仅用这一算法）。

`*`

星号是一个特殊值，可以代表任意资源。它只用在进行资源上传时，通常是采用 `PUT` 方法，来检测拥有相同识别 ID 的资源是否已经上传过了。

示例
--
```

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-None-Match: W/"67ab43", "54ed21", "7892dd"

If-None-Match: *
```

规范
--

| Specification |
| --- |
| HTTP Semantics # field.if-none-match |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

相关内容
----

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-Match`
* `304` `Not Modified`
* `412` `Precondition Failed`
Last-Modified
=============

**`Last-Modified`** 是一个响应首部，其中包含源头服务器认定的资源做出修改的日期及时间。它通常被用作一个验证器来判断接收到的或者存储的资源是否彼此一致。由于精确度比 `ETag` 要低，所以这是一个备用机制。包含有 `If-Modified-Since` 或 `If-Unmodified-Since` 首部的条件请求会使用这个字段。

| Header type | Response header |
| --- | --- |
| Forbidden header name | no |
| CORS-safelisted response-header | yes |

语法
--
```

Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

指令
--

<day-name>

"Mon", "Tue", "Wed", "Thu", "Fri", "Sat" 或 "Sun" 之一（区分大小写）。

<day>

两位数字表示的天数，例如"04" or "23"。

<month>

"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 之一（区分大小写）。

<year>

4 位数字表示的年份，例如 "1990" 或者"2016"。

<hour>

两位数字表示的小时数，例如 "09" 或者 "23"。

<minute>

两位数字表示的分钟数，例如"04" 或者 "59"。

<second>

两位数字表示的秒数，例如 "04" 或者 "59"。

`GMT`

国际标准时间。HTTP 中的时间均用国际标准时间表示，从来不使用当地时间。

示例
--
```

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
```

规范
--

| Specification |
| --- |
| HTTP Semantics # field.last-modified |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

相关内容
----

* `If-Modified-Since`
* `If-Unmodified-Since`
* `Etag`
Sec-CH-UA-Full-Version
======================

**已弃用:** 不再推荐使用该特性。虽然一些浏览器仍然支持它，但也许已从相关的 web 标准中移除，也许正准备移除或出于兼容性而保留。请尽量不要使用该特性，并更新现有的代码；参见本页面底部的兼容性表格以指导你作出决定。请注意，该特性随时可能无法正常工作。

 **安全上下文:** 此项功能仅在一些支持的浏览器的安全上下文（HTTPS）中可用。

**备注：** 这个标头将被 `Sec-CH-UA-Full-Version-List` 替代。

**`Sec-CH-UA-Full-Version`** 用户代理客户端提示请求标头提供用户代理完整的版本字符串。

|  |  |
| --- | --- |
| 标头类型 | Request header、客户端提示 |
| Forbidden header name | 是 |

语法
--


```http
Sec-CH-UA-Full-Version: <version>
```

### 指令

`<version>`

包含完整版本号的字符串，如“96.0.4664.93”。

示例
--

服务器请求 `Sec-CH-UA-Full-Version` 标头的方法是在任何来自客户端的请求*响应*中添加 `Accept-CH`，使用所需标头的名称作为它的令牌（token）：


```http
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Full-Version
```


客户端可以选择提供提示（hint），并将 `Sec-CH-UA-Full-Version` 标头添加到后续的请求中。例如，客户端可能会添加标头，如下所示：


```http
GET /GET /my/page HTTP/1.1
Host: example.site

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Full-Version: "96.0.4664.110"
Sec-CH-UA-Platform: "Windows"
```

规范
--

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-full-version |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

参见
--

* 客户端提示
* 用户代理客户端提示 API (en-US)
* 通过用户代理客户端提示改善用户隐私和开发人员体验（web.dev）
* `Accept-CH`
* HTTP 缓存 > Vary 响应和 `Vary`
Access-Control-Max-Age
======================

The **`Access-Control-Max-Age`** 这个响应头表示 preflight request （预检请求）的返回结果（即 `Access-Control-Allow-Methods` 和`Access-Control-Allow-Headers` 提供的信息）可以被缓存多久。

| 报头类型 | Response header |
| --- | --- |
| Forbidden header name | no |

语法
--
```

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

指令
--

<delta-seconds>

 返回结果可以被缓存的最长时间（秒）。
 在 Firefox 中，上限是 24 小时 （即 86400 秒）。
 在 Chromium v76 之前， 上限是 10 分钟（即 600 秒)。
 从 Chromium v76 开始，上限是 2 小时（即 7200 秒)。
 Chromium 同时规定了一个默认值 5 秒。
 如果值为 **-1**，表示禁用缓存，则每次请求前都需要使用 OPTIONS 预检请求。


示例
--

将预检请求的结果缓存 10 分钟：
```

Access-Control-Max-Age: 600
```

规范
--

| Specification |
| --- |
| Fetch Standard # http-access-control-max-age |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

相关内容
----

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Methods`
From
====

请求首部 **`From`** 中包含一个电子邮箱地址，这个电子邮箱地址属于发送请求的用户代理的实际掌控者的人类用户。

如果你在运行一个机器人代理程序（比如爬虫），那么 Form 首部应该随请求一起发送，这样的话，在服务器遇到问题的时候，例如机器人代理发送了过量的、不希望收到的或者不合法的请求，站点管理员可以联系到你。

**警告：** 不可以将 From 首部用于访问控制或者身份验证。


| Header type | Request header |
| --- | --- |
| Forbidden header name | no |

语法
--
```

From: <email>
```

指令
--

<email>

一个机器可识别的电子邮箱地址。

示例
--
```

From: webmaster@example.org
```

规范
--

| Specification |
| --- |
| HTTP Semantics # field.from |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

相关内容
----

* `Host`
If-Modified-Since
=================

**`If-Modified-Since`** 是一个条件式请求首部，服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 `200` 。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 `304` 响应，而在 `Last-Modified` 首部中会带有上次修改时间。不同于 `If-Unmodified-Since`, `If-Modified-Since` 只可以用在 `GET` 或 `HEAD` 请求中。

当与 `If-None-Match` 一同出现时，它（**`If-Modified-Since`**）会被忽略掉，除非服务器不支持 `If-None-Match`。

最常见的应用场景是来更新没有特定 `ETag` 标签的缓存实体。

| Header type | Request header |
| --- | --- |
| Forbidden header name | no |

语法
--
```

If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

指令
--

<day-name>

"Mon", "Tue", "Wed", "Thu", "Fri", "Sat" 或 "Sun" 之一（区分大小写）。

<day>

两位数字表示的天数，例如"04" or "23"。

<month>

"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 之一（区分大小写）。

<year>

4 位数字表示的年份，例如 "1990" 或者"2016"。

<hour>

两位数字表示的小时数，例如 "09" 或者 "23"。

<minute>

两位数字表示的分钟数，例如"04" 或者 "59"。

<second>

两位数字表示的秒数，例如 "04" 或者 "59"。

`GMT`

国际标准时间。HTTP 中的时间均用国际标准时间表示，从来不使用当地时间。

示例
--
```

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

规范
--

| Specification |
| --- |
| HTTP Semantics # field.if-modified-since |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

相关内容
----

* `ETag`
* `If-Unmodified-since`
* `If-Match`
* `If-None-Match`
* `304` `Not Modified`