recursal/MDN huggingface dataset:
原因：Did not find method in CORS header 'Access-Control-Allow-Methods'
====================================================================

原因
--
```

原因：Did not find method in CORS header 'Access-Control-Allow-Methods'
```

哪里错了？
-----

CORS 请求使用的 HTTP 方法不包含在响应的 `Access-Control-Allow-Methods` 标头指定的方法列表中。此标头指定了一个使用逗号分隔的 HTTP 方法列表，当使用 CORS 访问请求中指定的 URL 时，可以使用这些方法；如果请求使用任何其他方法，则会发生此错误。

例如，如果响应中包含：
```

Access-Control-Allow-Methods: GET,HEAD,POST
```


尝试使用 `PUT` 请求会因为这个错误失败。

请确保当访问服务时你的代码只使用了允许的 HTTP 方法。

**备注：** 如果服务器的 `Access-Control-Allow-methods` 标头中包含任何未识别的或未定义的方法名称，会出现不同的错误：原因：`Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'`。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
* HTTP 请求方法
原因：expected 'true' in CORS header 'Access-Control-Allow-Credentials'
====================================================================

原因
--
```

原因：expected 'true' in CORS header 'Access-Control-Allow-Credentials'
```

哪里出错了？
------

CORS 请求要求服务器允许使用凭据，但是服务器的 `Access-Control-Allow-Credentials` 标头的值并没有设置为 `true`。

想要在客户端解决此问题，请修改代码以不请求使用凭据：

* 如果要使用 `XMLHttpRequest` 发出请求，请确保没有将 `withCredentials` 设置为 `true`。
* 如果使用服务端发送事件，请确保 `EventSource.withCredentials` (en-US) 为 `false`（这是默认值）。
* 如果使用 Fetch API，请确保 `Request.credentials` 为 `"omit"`。

想要通过更改服务器的配置来消除此错误，请调整服务器的配置以将 `Access-Control-Allow-Credentials` 标头的值设置为 `true`。

参见
--

* CORS 错误
* 术语：CORS
* CORS 简介
原因：missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
================================================================================================

原因
--
```

原因：missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
```

哪里错了？
-----

`Access-Control-Allow-Headers` 标头由服务端发送，让客户端知道它支持哪些标头用于 CORS 请求。`Access-Control-Allow-Headers` 的值应该是逗号分隔的标头名称列表，例如“`X-Custom-Information`”或任何标准但非基本的标头名称（始终允许）。

尝试预检未明确允许的标头时会发生此错误（即，它不包含在服务器发送的 `Access-Control-Allow-Headers` 标头指定的列表中）。要解决此问题，需要更新服务器以允许指定的标头，或者需要避免使用该标头。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
* HTTP 标头
原因：invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
====================================================================

原因
--
```

原因：invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
```

哪里错了？
-----

服务器发送的对 CORS 请求的响应包含 `Access-Control-Allow-Headers` 标头，并且至少含有一个无效的标头名称。

`Access-Control-Allow-Headers` 标头通过服务器发送以响应预检请求；它让客户端知道 CORS 请求中允许哪些 HTTP 标头。如果客户端用户代理在逗号分隔的值中找到由该标头提供的任何它无法识别的标头名称，都会发生此错误。

这很有可能只能在服务端解决，方法是修改服务器的配置以不再发送带有 `Access-Control-Allow-Headers` 标头的无效或未知标头名称。检查以确保你的用户代理或者使用的客户端的 HTTP 库是最新的。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
* HTTP 标头
原因：CORS disabled
================

原因
--
```

原因：CORS disabled
```

哪里错了？
-----

发送了一个需要使用 CORS 的请求，但在用户的浏览器中禁用了 CORS。发生这种情况时，用户需要在浏览器中重新打开 CORS。

在 Firefox 中，禁用 CORS 的首选项是 `content.cors.disable`。将此设置为 `true` 将禁用 CORS，因此在这种情况下，CORS 请求将始终因此错误而失败。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
原因：CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
=================================================================

原因
--
```

原因：CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
```

出了什么问题？
-------

发出请求的源不能与 `Access-Control-Allow-Origin` 标头允许的源相匹配。如果响应包含多个 `Access-Control-Allow-Origin` 标头，也会发生此错误。

如果你代码使用 CORS 请求访问的服务在你的控制之下，请确保在它的 `Access-Control-Allow-Origin` 标头中包含了你的源。此外，确定响应中只有一个这样的标头，并且它只能包含一个单独的源。

例如，在 Apache 中，将以下行添加到服务器的配置中（在相应的 `<Directory>`、`<Location>`、`<Files>` 或 `<VirtualHost>` 部分中）。配置通常位于 `.conf` 文件中（`httpd.conf` 和 `apache.conf` 是这些文件的通用名称）或者位于 `.htaccess` 文件中。

**警告：** 你必须将 HTTPS 或 HTTP 协议作为源的一部分。
```

Header set Access-Control-Allow-Origin 'origin'
```


在 Nginx 中，对应的配置为：
```

add_header 'Access-Control-Allow-Origin' 'origin'
```

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
* 开启 CORS：我希望在自己的服务器上添加对 CORS 的支持
原因：CORS request external redirect not allowed
=============================================

原因
--
```

原因：CORS request external redirect not allowed
```

哪里错了？
-----

服务器响应了 CORS 请求，并将 HTTP 重定向到与原始请求不同源的 URL 上，这在 CORS 请求期间是不允许的。

例如，如果页面请求 `https://service.tld/fetchdata`，并且服务器的 HTTP 响应是“301 Moved Permanently”、“307 Temporary Redirect”或“308 Permanent Redirect”，并且 `Location` 是`https://anotherservice.net/getdata`，那么 CORS 请求将以这种方式失败。

要解决此问题，请更新代码以使用重定向报告的新 URL，从而避免重定向。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
原因：CORS request not HTTP
========================

原因
--
```

原因：CORS request not HTTP
```

哪里错了？
-----

CORS 请求只能用于 HTTP 或 HTTPS URL 方案，但请求指定的 URL 可能是不同类型。这种情况经常发生在 URL 指定本地文件，例如使用了 `file:///` 的 URL。

要解决此问题，请确保在发出涉及 CORS 的请求时使用 HTTPS URL，例如 `XMLHttpRequest`、Fetch API、Web 字体（`@font-face`）、WebGL 纹理以及 XSL 样式表。

### 加载本地文件

来自相同的目录或者子目录的本地文件在历史上被视为同源的。这意味着在测试期间可以从本地目录或子目录加载文件以及它的所有子资源，而不会触发 CORS 错误。

不幸地是，这有安全隐患，正如此公告所述：CVE-2019-11730。很多浏览器，包括 Firfox 和 Chrome，现在将所有本地文件视为*不透明*来源（默认）。因此，加载包含本地资源的本地文件现在会导致 CORS 错误。

开发者如果想要在本地进行测试，现在要设置一个本地服务器。由于所有的文件都来自同种方案和域（`loaclhost`），它们都有相同的源，并不会触发跨源错误。

**备注：** 此更改符合 URL 规范，该规范将文件的原始行为留给开发者实现，但建议在有疑问时，将文件的来源视为不透明。

参见
--

* CORS 错误
* CORS 介绍
* 什么是 URL？
原因：CORS header 'Origin' cannot be added
=======================================

原因
--
```

原因：CORS header 'Origin' cannot be added
```

哪里错了？
-----

用户代理不能把所需的 `Origin` 标头添加到 HTTP 请求中。所有的 CORS 请求必须有 `Origin` 标头。

例如，如果 JavaScript 代码以增强的权限运行，允许它访问多个域名的内容，则会发生这种情况。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
PUT
===

**HTTP `PUT` 请求方法**创建一个新的资源或用请求的有效载荷替换目标资源的表示。

`PUT` 与 `POST` 方法的区别是，`PUT` 方法是幂等的：调用一次与连续调用多次效果是相同的（即没有*副*作用），而连续调用多次相同的 `POST` 方法可能会有副作用，比如多次提交同一订单。

|  |  |
| --- | --- |
| 请求是否有主体 | 是 |
| 成功的响应是否有主体 | 可能有 |
| 安全 | 否 |
| 幂等 | 是 |
| 可缓存 | 否 |
| 允许在 HTML 表单中使用 | 不允许 |

语法
--


```http
PUT /new.html HTTP/1.1
```

示例
--

### 请求


```http
PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>新文件</p>
```

### 响应

如果目标资源没有当前的表示，并且 `PUT` 方法成功创建了资源，那么源服务器必须返回 `201`（`Created`）来通知用户代理资源已创建。


```http
HTTP/1.1 201 Created
Content-Location: /new.html
```


如果目标资源已经存在，并且依照请求中封装的表现形式成功进行了更新，那么，源服务器必须返回 `200`（`OK`）或 `204`（`No Content`）来表示请求成功完成。


```http
HTTP/1.1 204 No Content
Content-Location: /existing.html
```

规范
--

| Specification |
| --- |
| HTTP Semantics # PUT |

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

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

参见
--

* `201`
* `204`
OPTIONS
=======

**HTTP `OPTIONS` 方法**请求给定的 URL 或服务器的允许通信选项。客户端可以用这个方法指定一个 URL，或者用星号（`*`）来指代整个服务器。

|  |  |
| --- | --- |
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 是 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 否 |
| 允许在 HTML 表单中使用 | 不允许 |

语法
--


```http
OPTIONS /index.html HTTP/1.1
OPTIONS * HTTP/1.1
```

示例
--

### 检测服务器所支持的请求方法

要想知道一个服务器支持哪些请求方法，可以使用 `curl` 命令行程序来发出 `OPTIONS` 请求：


```bash
curl -X OPTIONS https://example.org -i
```


响应包含 `Allow` 标头，其值表明了服务器支持的所有 HTTP 方法：


```http
HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
```

### CORS 中的预检请求

在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。在这个示例中，我们会为这些参数请求权限：

* 在预检请求中发送的 `Access-Control-Request-Method` 标头告知服务器实际请求所使用的 HTTP 方法，在这里将实际使用 `POST` 请求方法。
* `Access-Control-Request-Headers` 标头告知服务器实际请求所携带的自定义标头，在这里会使用 `X-PINGOTHER` 和 `Content-Type` 标头。


```http
OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.example
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```


服务器现在可以回应是否会接受这些情况下的请求。在这个例子中，服务器的响应说明了：

`Access-Control-Allow-Origin`

`https://foo.example` 源被允许通过以下方式请求 `bar.example/resources/post-here/` URL：

`Access-Control-Allow-Methods`

`POST`、`GET` 和 `OPTIONS` 是该 URL 允许的方法（该标头类似于 `Allow` 响应标头，但只用于 CORS）。

`Access-Control-Allow-Headers`

`X-PINGOTHER` 和 `Content-Type` 是该 URL 允许的请求标头。

`Access-Control-Max-Age`

以上权限可以缓存 86400 秒（1 天）。


```http
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
```

状态码
---

`200` OK 和 `204` No Content 都是允许的状态码，但是部分浏览器错误地认为 `204 No Content` 也适用于该资源，且不发送后续请求来获取资源内容。

规范
--

| Specification |
| --- |
| HTTP Semantics # OPTIONS |

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

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

参见
--

* `Allow` 标头
* CORS
DELETE
======

**HTTP `DELETE` 请求方法**用于删除指定的资源。

|  |  |
| --- | --- |
| 请求是否有主体 | 可能有 |
| 成功的响应是否有主体 | 可能有 |
| 安全 | 否 |
| 幂等 | 是 |
| 可缓存 | 否 |
| 允许在 HTML 表单中使用 | 不允许 |

语法
--


```http
DELETE /file.html HTTP/1.1
```

示例
--

### 请求


```http
DELETE /file.html HTTP/1.1
Host: example.com
```

### 响应

如果 `DELETE` 方法成功执行，那么可能会有以下几种状态码：

* 状态码 `202`（`Accepted`）表示请求的操作可能会成功执行，但是尚未开始执行。
* 状态码 `204`（`No Content`）表示操作已执行，但是没有进一步的相关信息。
* 状态码 `200`（`OK`）表示操作已执行，并且响应中提供了相关状态的描述信息。


```http
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT

<html>
  <body>
    <h1>文件已删除。</h1>
  </body>
</html>
```

规范
--

| Specification |
| --- |
| HTTP Semantics # DELETE |

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

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

参见
--

* HTTP 状态码：`200`、`202`、`204`
GET
===

**HTTP `GET` 方法**请求指定资源的表示。使用 `GET` 的请求应该只用于请求数据，而不应该包含数据。

**备注：** 在 `GET` 请求中发送请求体或有效载荷可能会导致一些现有的实现拒绝该请求——虽然规范没有禁止，但语义没有定义。最好是避免在 `GET` 请求中发送有效载荷。


|  |  |
| --- | --- |
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 是 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 是 |
| 允许在 HTML 表单中使用 | 允许 |

语法
--


```http
GET /index.html
```

规范
--

| Specification |
| --- |
| HTTP Semantics # GET |

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

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

参见
--

* HTTP 标头
* `Range`
* `POST`
HEAD
====

**HTTP `HEAD` 方法**请求资源的标头信息，并且这些标头与 HTTP `GET` 方法请求时返回的一致。该请求方法的一个使用场景是在下载一个大文件前先通过 `HEAD` 请求读取其 `Content-Length` 标头的值获取文件的大小，而无需实际下载文件，以此可以节约带宽资源。

**警告：** `HEAD` 方法的响应*不应*包含响应主体。即使包含了响应主体，也*必须*忽略掉：任何（可能用于描述错误响应主体的）表示标头会被假定为在发送相似的 `GET` 请求时也会接收到。

如果对 `HEAD` 请求的响应显示一个缓存的 URL 响应现在已经过期，即使没有发出 `GET` 请求，缓存的副本也会失效。

|  |  |
| --- | --- |
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 否 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 是 |
| 允许在 HTML 表单中使用 | 不允许 |

语法
--


```http
HEAD /index.html
```

规范
--

| Specification |
| --- |
| HTTP Semantics # HEAD |

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

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

参见
--

* `GET`
TRACE
=====

**HTTP `TRACE` 方法**沿着通往目标资源的路径进行信息回环测试，提供一个有用的调试机制。

请求的最终接收者应将收到的信息（不包括下面描述的一些字段）作为 `200`（`OK`）响应的信息主体反映给客户端，其 `Content-Type` 为 `message/http`。最终接收者是源服务器或第一个在请求中收到 `Max-Forwards` 值为 0 的服务器。

|  |  |
| --- | --- |
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 否 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 否 |
| 允许在 HTML 表单中使用 | 不允许 |

语法
--


```http
TRACE /index.html
```

规范
--

| Specification |
| --- |
| HTTP Semantics # TRACE |

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

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

参见
--

* HTTP 方法
PATCH
=====

**HTTP `PATCH` 请求方法**用于对资源进行部分修改。

`PATCH` 有点类似于 CRUD 中的“更新”概念（一般来说，HTTP 与 CRUD 不同，两者不应混淆）。

`PATCH` 请求是一组关于如何修改资源的指令，与 `PUT` 形成对比；后者是一个资源的完整表述。

`PATCH` 并不需要是幂等的，这与 `PUT` 形成鲜明对比；后者始终是幂等的。“幂等（idempotent）”一词意味着，任何数量的重复、相同的请求都会使资源处于相同的状态。例如，如果一个自动递增的计数器字段是资源的一个组成部分，那么 `PUT` 将自然地覆盖它（因为它覆盖一切），但对于 `PATCH` 则不一定如此。

`PATCH` 像 `POST` 一样，*可能*会对其他资源产生副作用。

要知道一个服务器是否支持 `PATCH`，服务器可以通过将其加入 `Allow` 或 `Access-Control-Allow-Methods`（用于 CORS）响应标头中的列表来宣告其支持。

另外一个（隐式）表明允许 `PATCH` 方法的指示为 `Accept-Patch` 标头的存在，这个标头明确了服务器端可以接受补丁文档的格式。

|  |  |
| --- | --- |
| 请求是否有主体 | 是 |
| 成功的响应是否有主体 | 可能有 |
| 安全 | 否 |
| 幂等 | 否 |
| 可缓存 | 否 |
| 允许在 HTML 表单中使用 | 不允许 |

语法
--


```http
PATCH /file.txt HTTP/1.1
```

示例
--

### 请求


```http
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[描述变化情况]
```

### 响应

任何 2xx 状态码都代表成功的响应。

以下示例使用了 `204` 响应码，因为响应不携带任何主体。`200` 响应可能携带了响应体。


```http
HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
```

规范
--

| Specification |
| --- |
| RFC 5789  |

参见
--

* `204`
* `Allow`、`Access-Control-Allow-Methods`
* `Accept-Patch`——指定了可以接受的补丁文档的格式。
CONNECT
=======

**HTTP `CONNECT` 方法**可以开启与所请求资源之间的双向沟通的通道。它可以用来创建隧道（tunnel）。

例如，**`CONNECT`** 可以用来访问采用了 SSL（HTTPS）协议的站点。客户端要求 HTTP 代理服务器将 TCP 连接作为通往目的主机的隧道。之后该服务器会代替客户端与目的主机建立连接。连接建立好之后，代理服务器会面向客户端发送或接收 TCP 数据流。

`CONNECT` 是一个逐跳（hop-by-hop）的方法。

|  |  |
| --- | --- |
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 否 |
| 安全 | 否 |
| 幂等 | 否 |
| 可缓存 | 否 |
| 允许在 HTML 表单中使用 | 不允许 |

语法
--


```http
CONNECT www.example.com:443 HTTP/1.1
```

示例
--

一些代理服务器在创建隧道时会要求进行身份验证。参见 `Proxy-Authorization` 标头。


```http
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
```

规范
--

| Specification |
| --- |
| HTTP Semantics # CONNECT |

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

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

参见
--

* 代理服务器
* `Proxy-Authorization`
POST
====

**HTTP `POST` 方法**发送数据给服务器。请求主体的类型由 `Content-Type` 标头指定。

`PUT` 和 `POST` 方法的区别是，`PUT` 方法是幂等的：调用一次与连续调用多次效果是相同的（即没有*副*作用），而连续调用多次相同的 `POST` 方法可能会有副作用，比如多次提交同一订单。

一个 `POST` 请求通常是通过 HTML 表单发送的，并导致服务器的相应修改。在这种情况下，内容类型（content type）是通过在 `<form>` 元素中设置正确的 `enctype` 属性，或是在 `<input>` 和 `<button>` 元素中设置 `formenctype` 属性来选择的：

* `application/x-www-form-urlencoded`：数据被编码成以 `'&'` 分隔的键值对，同时以 `'='` 分隔键和值。键和值中非字母或数字的字符会被 URL 编码，这也是这种类型不支持二进制数据的原因（应使用 `multipart/form-data` 代替）。
* `multipart/form-data`：每个值是在一块数据（“主体部分”）中发送的，由用户代理指定的分隔符（“boundary”）将每个部分分离开。键值在每个部分的 `Content-Disposition` 标头中给出。
* `text/plain`

当 `POST` 请求是通过除 HTML 表单之外的方式（例如使用 `XMLHttpRequest`）发送时，请求主体可以是任何类型。正如 HTTP 1.1 规范中所描述的那样，`POST` 被设计用于以统一的方法来涵盖以下功能：

* 对现有资源进行注释
* 在公告板，新闻组，邮件列表或类似的文章组中发布消息;
* 通过注册模板新增用户;
* 向数据处理过程提供一批数据，例如提交一个表单;
* 通过追加操作，扩展数据库数据。

|  |  |
| --- | --- |
| 请求是否有主体 | 是 |
| 成功的响应是否有主体 | 是 |
| 安全 | 否 |
| 幂等 | 否 |
| 可缓存 | 仅在包含足够新的信息时 |
| 允许在 HTML 表单中使用 | 允许 |

语法
--


```http
POST /test
```

示例
--

使用默认的 `application/x-www-form-urlencoded` 作为 content type 的简单表单：


```http
POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field1=value1&field2=value2
```


使用 `multipart/form-data` 作为 content type 的表单：


```http
POST /test HTTP/1.1
Host: foo.example
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
--boundary--
```

规范
--

| Specification |
| --- |
| HTTP Semantics # POST |

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

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

参见
--

* `Content-Type`
* `Content-Disposition`
* `GET`
202 Accepted
============

响应状态码 **202 Accepted** 表示服务器端已经收到请求消息，但是尚未进行处理。但是对于请求的处理却是无保证的，即稍后无法通过 HTTP 协议给客户端发送一个异步请求来告知其请求的处理结果。这个状态码被设计用来将请求交由另外一个进程或者服务器来进行处理，或者是对请求进行批处理的情形。

状态
--
```

202 Accepted
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.202 |

相关内容
----

* `Accept`
505 HTTP Version Not Supported
==============================

**`505 HTTP Version Not Supported`** 是一种 HTTP 协议的服务器端错误状态代码，表示服务器不支持请求所使用的 HTTP 版本。

状态
--
```

505 HTTP Version Not Supported
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.505 |

相关内容
----

* `Upgrade` (en-US)
403 Forbidden
=============

状态码 **`403 Forbidden`** 代表客户端错误，指的是服务器端有能力处理该请求，但是拒绝授权访问。

这个状态类似于 `401`，但进入 `403`状态后即使重新验证也不会改变该状态。该访问是长期禁止的，并且与应用逻辑密切相关（例如没有足够的权限访问该资源）。

状态
--
```

403 Forbidden
```

响应示例
----


```http
HTTP/1.1 403 Forbidden
Date: Wed, 21 Oct 2015 07:28:00 GMT
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.403 |

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

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

参见
--

* `401`
* http 状态码定义
304 Not Modified
================

HTTP **`304 Not Modified`** 说明无需再次传输请求的内容，也就是说可以使用缓存的内容。这通常是在一些安全的方法（safe），例如`GET` 或`HEAD` 或在请求中附带了头部信息： `If-None-Match` 或`If-Modified-Since`。

如果是 `200` `OK` ，响应会带有头部 `Cache-Control`, `Content-Location`, `Date`, `ETag`, `Expires`，和 `Vary`.

**备注：** 很多浏览器的 开发者工具 会发出额外的请求，以达到 `304` 的目的，这样可以把资源以本地缓存的形式展现给开发者。

状态
--
```

304 未改变
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.304 |

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

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

兼容性提醒
-----

* 如果响应错误的携带了响应体，那么浏览器会有不同的行为，详情请见 204 No Content 。
更多
--

* `If-Modified-Since`
* `If-None-Match`
501 Not Implemented
===================

HTTP **`501 Not Implemented`** 服务器错误响应码表示请求的方法不被服务器支持，因此无法被处理。服务器必须支持的方法（即不会返回这个状态码的方法）只有 `GET` 和 `HEAD`。

请注意，你无法修复 501 错误，需要被访问的 web 服务器去修复该问题。

**备注：** 501 响应默认是可缓存的。

状态
--
```

501 Not Implemented
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.501 |

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

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
206 Partial Content
===================

HTTP **`206 Partial Content`** 成功状态响应代码表示请求已成功，并且主体包含所请求的数据区间，该数据区间是在请求的 `Range` 首部指定的。

如果只包含一个数据区间，那么整个响应的 `Content-Type` 首部的值为所请求的文件的类型，同时包含 `Content-Range` 首部。

如果包含多个数据区间，那么整个响应的 `Content-Type` 首部的值为 `multipart/byteranges` ，其中一个片段对应一个数据区间，并提供 `Content-Range` 和 `Content-Type` 描述信息。

状态
--
```

206 Partial Content
```

示例
--

只包含一个数据区间的响应：
```

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...
```


包含多个数据区间的响应：
```

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=String_separator

--String_separator
Content-Type: application/pdf
Content-Range: bytes 234-639/8000

...the first range...
--String_separator
Content-Type: application/pdf
Content-Range: bytes 4590-7999/8000

...the second range
--String_separator--
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.206 |

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

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

参见
--

* `If-Range`
* `Range`
* `Content-Range`
* `Content-Type`
300 Multiple Choices
====================

**`300 Multiple Choices`** 是一个用来表示重定向的响应状态码，表示该请求拥有多种可能的响应。用户代理或者用户自身应该从中选择一个。由于没有如何进行选择的标准方法，这个状态码极少使用。

假如服务器可以提供一个优先选择，那么它应该生成一个 `Location` 首部。

状态
--
```

300 Multiple Choices
```

示例
--

参考这个页面： w3.org page for a Multiple Choice response.

规范
--

| Specification |
| --- |
| HTTP Semantics # status.300 |

相关内容
----

* `301` `Moved Permanently`
* `302` `Found`, the temporary redirect
* `308` `Permanent Redirect`
407 Proxy Authentication Required
=================================

状态码 **`407 Proxy Authentication Required`** 代表客户端错误，指的是由于缺乏位于浏览器与可以访问所请求资源的服务器之间的代理服务器（proxy server ）要求的身份验证凭证，发送的请求尚未得到满足。

这个状态码会与 `Proxy-Authenticate` 首部一起发送，其中包含有如何进行验证的信息。

状态
--
```

407 Proxy Authentication Required
```

响应示例
----
```

HTTP/1.1 407 Proxy Authentication Required
Date: Wed, 21 Oct 2015 07:28:00 GMT
Proxy-Authenticate: Basic realm="Access to internal site"
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.407 |

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

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

相关内容
----

* HTTP authentication
* `WWW-Authenticate`
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`
413 Content Too Large
=====================

HTTP 响应状态码 **`413 Content Too Large`** 表示请求主体的大小超过了服务器愿意或有能力处理的限度，服务器可能会关闭连接或返回 `Retry-After` 标头字段。

在 RFC 9110 标准之前，该响应的短语为 **`Payload Too Large`**，它仍在被广泛使用。

状态
--


```http
413 Content Too Large
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.413 |

参见
--

* `Connection`
* `Retry-After`
422 Unprocessable Entity
========================

HTTP 422 状态码表示服务器理解请求实体的内容类型，并且请求实体的语法是正确的，但是服务器无法处理所包含的指令。

**警告：** 客户端不应在不修改的情况下重复发送此请求。

状态码
---
```

422 Unprocessable Entity
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.422 |
511 Network Authentication Required
===================================

**`511 Network Authentication Required`** 是一种 HTTP 协议的错误状态代码，表示客户端需要通过验证才能使用该网络。

该状态码不是由源头服务器生成的，而是由控制网络访问的拦截代理服务器生成的。

网络运营商们有时候会在准许使用网络之前要求用户进行身份验证、接受某些条款，或者进行其他形式的与用户之间的互动（例如在网络咖啡厅或者机场）。他们通常用用户设备的 MAC 地址来进行识别。

状态
--
```

511 Network Authentication Required
```

规范
--

| Specification |
| --- |
| RFC 6585 # section-6 |

相关内容
----

* Proxy server
308 Permanent Redirect
======================

在 HTTP 协议中， **308 Permanent Redirect**（永久重定向）是表示重定向的响应状态码，说明请求的资源已经被永久的移动到了由 `Location` 首部指定的 URL 上。浏览器会进行重定向，同时搜索引擎也会更新其链接（用 SEO 的行话来说，意思是“链接汁”（link juice）被传递到了新的 URL）。

在重定向过程中，请求方法和消息主体不会发生改变，然而在返回 `301` 状态码的情况下，请求方法有时候会被客户端错误地修改为 `GET` 方法。

**备注：** 一些 Web 应用可能会将 308 Permanent Redirect 以一种非标准的方式使用以及用作其他用途。例如，Google Drive 会使用 308 Resume Incomplete 状态码来告知客户端文件上传终止且不完整。[1]

状态
--
```

308 Permanent Redirect
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.308 |

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

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

更多可见
----

* `301` `Moved Permanently`
* `302` `Found`, the temporary redirect
426 Upgrade Required
====================

**`426 Upgrade Required`** 是一种 HTTP 协议的错误状态代码，表示服务器拒绝处理客户端使用当前协议发送的请求，但是可以接受其使用升级后的协议发送的请求。

服务器会在响应中使用 `Upgrade` (en-US) 首部来指定要求的协议。

状态
--
```

426 Upgrade Required
```

示例
--
```

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.426 |

相关内容
----

* `Upgrade` (en-US)
* `101` `Switching Protocol`
100 Continue
============

HTTP **`100 Continue`** 信息型状态响应码表示目前为止一切正常，客户端应该继续请求，如果已完成请求则忽略。

为了让服务器检查请求的首部，客户端必须在发送请求实体前，在初始化请求中发送 `Expect: 100-continue` 首部并接收 `100 Continue` 响应状态码。

状态码
---
```

100 Continue
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.100 |

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

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

另见
--

* `Expect`
* `417`
417 Expectation Failed
======================

HTTP 协议中的 **`417 Expectation Failed`** 状态码表示客户端错误，意味着服务器无法满足 `Expect` 请求消息头中的期望条件。

参考 `Expect` 消息头获得更多的相关细节信息。

状态码
---
```

417 Expectation Failed
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.417 |

参见
--

* `Expect`
412 Precondition Failed
=======================

在 HTTP 协议中，响应状态码 **412 Precondition Failed**（先决条件失败）表示客户端错误，意味着对于目标资源的访问请求被拒绝。这通常发生于采用除 `GET` 和 `HEAD` 之外的方法进行条件请求时，由首部字段 `If-Unmodified-Since` 或 `If-None-Match` 规定的先决条件不成立的情况下。这时候，请求的操作——通常是上传或修改文件——无法执行，从而返回该错误状态码。

状态码
---
```

412 Precondition Failed
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.412 |

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

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

参见
--

* `304`
* `If-Unmodified-Since`
* `If-None-Match`
* `428`
423 Locked
==========

**备注：** *锁定*资源的能力仅限于某些 WebDAV 服务器。访问网页的浏览器永远不会遇到这种状态代码；在发生错误的情况下，浏览器会将其作为通用的 `400` 状态代码处理。

HTTP **`423 Locked`** 错误响应状态码表示暂定目标资源被*锁定*，即无法访问。其内容应包含一些 WebDAV XML 格式的信息。

状态
--


```http
423 Locked
```

### 示例


```http
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
  <D:lock-token-submitted>
    <D:href>/workspace/webdav/</D:href>
  </D:lock-token-submitted>
</D:error>
```

规范
--

| Specification |
| --- |
| RFC 4918 # section-11.3 |
510 Not Extended
================

HTTP 协议的 **`510 Not Extended`** 响应状态码在 HTTP 扩展框架协议（参见 RFC 2774）中发送。

在 HTTP 扩展框架协议中，一个客户端可以发送一个包含扩展声明的请求，该声明描述了要使用的扩展。如果服务器接收到这样的请求，但是请求不支持任何所描述的扩展，那么服务器将使用 510 状态码进行响应。

Status
------
```

510 Not Extended
```

Specifications
--------------

| Specification |
| --- |
| RFC 2774 # section-7 |
508 Loop Detected
=================

HTTP 协议的 **`508 Loop Detected`** 状态码可以在 WebDAV 协议（基于 Web 的分布式创作和版本控制）中给出。

508 码表示服务器中断一个操作，因为它在处理具有“Depth: infinity”的请求时遇到了一个无限循环。508 码表示整个操作失败。

Status
------
```

508 Loop Detected
```

Specifications
--------------

| Specification |
| --- |
| RFC 5842 # section-7.2 |