9. Method Definitions (方法定义)

HTTP/1.1 的常用方法集定义如下。虽然可以扩展此集合，但不能假定额外的方法对于单独扩展的客户端和服务器共享相同的语义。

Host 请求头字段（第 14.23 节）必须 (MUST) 伴随所有 HTTP/1.1 请求。

9.1 Safe and Idempotent Methods (安全和幂等方法)

9.1.1 Safe Methods (安全方法)

实现者应该意识到，软件代表用户在互联网上进行交互，并且应该小心让用户意识到他们可能采取的任何对自己或他人可能具有意外意义的行动。

特别是，已经建立的约定是，GET 和 HEAD 方法不应该 (SHOULD NOT) 具有除检索之外的操作意义。这些方法应该被认为是"安全的" (safe)。这允许用户代理以特殊方式表示其他方法，例如 POST、PUT 和 DELETE，以便让用户意识到正在请求可能不安全的操作。

自然地，无法确保服务器在执行 GET 请求时不会产生副作用；事实上，一些动态资源认为这是一个特性。这里的重要区别在于用户没有请求副作用，因此不能为它们负责。

9.1.2 Idempotent Methods (幂等方法)

方法也可以具有"幂等性" (idempotence) 的属性，即（除了错误或过期问题）N > 0 个相同请求的副作用与单个请求相同。方法 GET、HEAD、PUT 和 DELETE 共享此属性。此外，方法 OPTIONS 和 TRACE 不应该 (SHOULD NOT) 有副作用，因此本质上是幂等的。

但是，可能一系列几个请求是非幂等的，即使该序列中的所有方法都是幂等的也是如此。（例如，如果结果或任何资源的状态取决于序列中的多个请求。）POST 请求不是幂等的。

9.2 OPTIONS

OPTIONS 方法表示请求有关请求-响应链上可用的通信选项的信息。此方法允许客户端确定与资源相关的选项和/或要求，或服务器的功能，而无需暗示资源操作或发起资源检索。

此方法的响应不可缓存。

如果 OPTIONS 请求包含实体主体（由 Content-Length 或 Transfer-Encoding 的存在指示），则必须 (MUST) 通过 Content-Type 字段指示媒体类型。虽然本规范没有定义任何此类主体的使用，但未来的 HTTP 扩展可能会使用 OPTIONS 主体向服务器提供更详细的查询信息。不支持此类扩展的服务器可以 (MAY) 丢弃请求主体。

如果 Request-URI 是星号（""），则 OPTIONS 请求通常适用于服务器，而不是特定资源。由于服务器的通信选项通常取决于资源，因此 "" 请求仅用作"ping"或"no-op"类型的方法；除了允许客户端测试服务器的功能之外，它不会做任何事情。例如，这可用于测试代理的 HTTP/1.1 合规性（或缺乏合规性）。

如果 Request-URI 不是星号，则 OPTIONS 请求仅适用于与该资源通信时可用的选项。

200 响应应该 (SHOULD) 包含任何指示可选功能的头字段，如果它们适用于该资源（例如，Allow），可能包括本规范未定义的扩展。如果包括响应主体，则它应该 (SHOULD) 包括有关通信选项的信息。此规范未定义该主体的格式，但可能在 HTTP 的未来扩展中定义。内容协商可用于选择适当的响应格式。如果不包括响应主体，则响应必须 (MUST) 包括 Content-Length 字段，其字段值为"0"。

Max-Forwards 请求头字段可以 (MAY) 用于将请求定向到请求链上的特定代理。当代理接收到允许转发请求的 OPTIONS 请求时，代理必须 (MUST) 检查 Max-Forwards 字段。如果 Max-Forwards 字段值为零（"0"），则代理禁止 (MUST NOT) 转发消息；相反，代理应该 (SHOULD) 以自己的通信选项响应。如果 Max-Forwards 字段值是大于零的整数，则代理必须 (MUST) 递减字段值并将请求转发到下一跳服务器。如果 OPTIONS 请求中不存在 Max-Forwards 字段，则转发代理禁止 (MUST NOT) 添加 Max-Forwards 字段。

9.3 GET

GET 方法表示检索由 Request-URI 标识的任何信息（以实体的形式）。如果 Request-URI 引用数据生成过程，则应该将生成的数据作为响应中的实体返回，而不是过程的源文本，除非该文本恰好是过程的输出。

如果请求消息包含 If-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match 或 If-Range 头字段，则 GET 的语义更改为"条件 GET" (conditional GET)。条件 GET 方法请求仅在条件头字段描述的情况下传输实体。条件 GET 方法旨在通过允许在不需要多个请求或传输客户端已经持有的数据的情况下刷新缓存的实体来减少不必要的网络使用。

如果请求消息包含 Range 头字段，则 GET 的语义更改为"部分 GET" (partial GET)。部分 GET 请求仅传输实体的一部分，如第 14.35 节所述。部分 GET 方法旨在通过允许在不传输客户端已经持有的数据的情况下完成部分检索的实体来减少不必要的网络使用。

对 GET 请求的响应是可缓存的，当且仅当它满足第 13 节中描述的 HTTP 缓存要求。

有关 GET 和 HEAD 方法的特殊注意事项，请参见第 15.1.3 节中的安全考虑。

9.4 HEAD

HEAD 方法与 GET 相同，只是服务器禁止 (MUST NOT) 在响应中返回消息主体。响应 HEAD 请求的 HTTP 头中包含的元信息应该 (SHOULD) 与响应 GET 请求时发送的信息相同。此方法可用于获取有关请求暗示的实体的元信息，而无需传输实体主体本身。此方法通常用于测试超文本链接的有效性、可访问性和最近修改。

对 HEAD 请求的响应可以 (MAY) 是可缓存的，因为响应中包含的信息可用于更新先前从该资源缓存的实体。如果新的字段值指示缓存的实体与当前实体不同（如 Content-Length、Content-MD5、ETag 或 Last-Modified 的更改所示），则缓存必须 (MUST) 将缓存条目视为陈旧。

9.5 POST

POST 方法用于请求源服务器接受请求中包含的实体作为 Request-URI 标识的资源的新从属。POST 旨在允许统一方法覆盖以下功能：

• 现有资源的注释；
• 向公告板、新闻组、邮件列表或类似的文章组发布消息；
• 提供数据块（例如提交表单）到数据处理过程；
• 通过追加操作扩展数据库。

POST 方法执行的实际功能由服务器确定，通常取决于 Request-URI。发布的实体从属于该 URI，就像文件从属于包含它的目录、新闻文章从属于发布到的新闻组或记录从属于数据库一样。

POST 方法执行的操作可能不会导致可由 URI 标识的资源。在这种情况下，200（OK）或 204（No Content）是适当的响应状态，具体取决于响应是否包括描述结果的实体。

如果资源已在源服务器上创建，则响应应该 (SHOULD) 是 201（Created）并包含描述请求状态并引用新资源的实体，以及 Location 头（参见第 14.30 节）。

对此方法的响应不可缓存，除非响应包括适当的 Cache-Control 或 Expires 头字段。但是，303（See Other）响应可用于指示用户代理检索可缓存的资源。

POST 请求必须 (MUST) 遵守第 8.2 节中描述的消息传输要求。

有关 POST 方法的缓存注意事项，请参见第 13.4 节。

9.6 PUT

PUT 方法请求将包含的实体存储在提供的 Request-URI 下。如果 Request-URI 引用已经存在的资源，则应该将包含的实体视为驻留在源服务器上的那个资源的修改版本。如果 Request-URI 不指向现有资源，并且该 URI 能够由请求用户代理定义为新资源，则源服务器可以 (can) 用该 URI 创建资源。如果创建了新资源，源服务器必须 (MUST) 通过 201（Created）响应通知用户代理。如果修改了现有资源，则应该 (SHOULD) 发送 200（OK）或 204（No Content）响应代码以指示成功完成请求。如果无法使用 Request-URI 创建或修改资源，则应该 (SHOULD) 给出反映问题性质的适当错误响应。实体的接收方禁止 (MUST NOT) 忽略它不理解或不实现的任何 Content-*（例如 Content-Range）头，并且必须 (MUST) 在这种情况下返回 501（Not Implemented）响应。

如果请求通过缓存传递，并且 Request-URI 标识一个或多个当前缓存的实体，则应该 (SHOULD) 将这些条目视为陈旧。对此方法的响应不可缓存。

PUT 和 POST 请求之间的根本区别反映在 Request-URI 的不同含义中。POST 请求中的 URI 标识将处理包含实体的资源。该资源可能是数据接受过程、某些其他协议的网关或接受注释的单独实体。相反，PUT 请求中的 URI 标识随请求包含的实体——用户代理知道打算使用什么 URI，服务器禁止 (MUST NOT) 尝试将请求应用于其他资源。如果服务器希望将请求应用于不同的 URI，它必须 (MUST) 发送 301（Moved Permanently）响应；然后用户代理可以 (MAY) 自行决定是否重定向请求。

单个资源可以由许多不同的 URI 标识。例如，文章可能具有用于标识"当前版本"的 URI，该 URI 与用于标识每个特定版本的 URI 不同。在这种情况下，通用 URI 的 PUT 请求可能会导致其他 URI 由源服务器定义。

HTTP/1.1 不定义 PUT 方法如何影响源服务器的状态。

PUT 请求必须 (MUST) 遵守第 8.2 节中描述的消息传输要求。

除非另有特殊要求，PUT 方法的副作用应该 (SHOULD) 与发送相同 Request-URI 的 GET 请求的副作用相同。

9.7 DELETE

DELETE 方法请求源服务器删除由 Request-URI 标识的资源。此方法可以 (MAY) 在源服务器上被人为干预（或其他方式）覆盖。即使从源服务器返回的状态码指示操作已成功完成，客户端也无法保证操作已执行。但是，服务器不应该 (SHOULD NOT) 指示成功，除非在给出响应时它打算删除资源或将其移动到不可访问的位置。

即使无法知道操作是否已成功执行，成功的响应也应该 (SHOULD) 是 200（OK）（如果操作很可能已成功执行）、202（Accepted）（如果操作尚未执行）或 204（No Content）（如果操作已执行但响应不包括实体）。

如果请求通过缓存传递，并且 Request-URI 标识一个或多个当前缓存的实体，则应该 (SHOULD) 将这些条目视为陈旧。对此方法的响应不可缓存。

9.8 TRACE

TRACE 方法用于调用沿着到目标资源的路径的请求消息的远程应用层环回。最终接收方的请求应该 (SHOULD) 将接收到的消息作为 200（OK）响应的实体主体反映回客户端。最终接收方是源服务器或接收到 Max-Forwards 值为零（0）的请求的第一个代理或网关（参见第 14.31 节）。TRACE 请求禁止 (MUST NOT) 包括实体。

TRACE 允许客户端查看在请求链的另一端接收到的内容，并使用该数据进行测试或诊断信息。Via 头字段（第 14.45 节）的值特别令人感兴趣，因为它充当请求链的跟踪。使用 Max-Forwards 头允许客户端限制请求链的长度，这对于测试无限循环中转发消息的代理链很有用。

如果请求有效，则响应应该 (SHOULD) 在实体主体中包含整个请求消息，Content-Type 为 "message/http"。对此方法的响应禁止 (MUST NOT) 缓存。

9.9 CONNECT

本规范保留方法名称 CONNECT 供与可以动态切换到隧道的代理一起使用（例如，SSL 隧道 [44]）。