HTTP/1.1 的通用方法集定义如下。尽管这个集合可以被扩展，但不能假设额外的方法对单独扩展的客户和服务器来说具有相同的语义。

所有 HTTP/1.1 请求都必须有 Host 请求头字段（第 14.23 节）。

9.1 安全和幂等的方法

9.1.1 安全方法

实施者应该意识到，软件代表着用户在互联网上的互动，应该注意让用户意识到他们可能采取的任何行动，可能对他们自己或其他人有意外的意义。

特别是，已经建立了一个惯例，即 GET 和 HEAD 方法不应该具有除检索以外的行动意义。这些方法应该被认为是 “安全的”。这允许用户代理以一种特殊的方式表示其他方法，如 POST、PUT 和 DELETE，以便让用户意识到正在请求一个可能不安全的动作的事实。

自然，不可能保证服务器不会因为执行 GET 请求而产生副作用；事实上，一些动态资源认为这是一个特点。这里的重要区别是，用户并没有要求产生副作用，所以不能对其负责。

9.1.2 幂等方法

方法也可以有 “幂等” 的属性，即（除了错误或过期问题）N>0 个相同请求的副作用与单个请求相同。GET、HEAD、PUT 和 DELETE 等方法都有这个属性。另外，方法 OPTIONS 和 TRACE 不应该有副作用，所以本质上是等效的。

然而，一个由几个请求组成的序列有可能是非幂等的，即使该序列中执行的所有方法都是幂等的。(如果对整个序列的一次执行总是产生一个结果，而这个结果不会因为对该序列的全部或部分的重新执行而改变，那么该序列就是幂等的）。) 例如，如果一个序列的结果依赖于一个后来在同一序列中被修改的值，那么这个序列就是非幂等的。

根据定义，一个从不产生副作用的序列是幂等的（前提是在同一组资源上没有并发的操作被执行）。

9.2 OPTIONS

OPTIONS 方法表示对由 Request-URI 确定的请求/响应链上可用的通信选项信息的请求。这种方法允许客户端确定与资源相关的选项和/或要求，或服务器的能力，而不意味着资源行动或启动资源检索。

对该方法的响应是不可缓存的。

如果 OPTIONS 请求包括一个实体主体（由 Content-Length 或 Transfer-Encoding 的存在表示），那么媒体类型必须由 Content-Type 字段表示。尽管本规范没有定义这种主体的任何用途，但未来对 HTTP 的扩展可能会使用 OPTIONS 主体来对服务器进行更详细的查询。不支持这种扩展的服务器可能会丢弃请求体。

如果 Request-URI 是一个星号（”“），则 OPTIONS 请求旨在适用于一般的服务器，而不是特定的资源。由于服务器的通信选项通常取决于资源，”“ 请求只作为一种 “ping” 或 “no-op” 类型的方法有用；它除了允许客户机测试服务器的能力外，没有任何作用。例如，这可以用来测试一个代理是否符合 HTTP/1.1 标准（或不符合）。

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

200 响应应该包括表明由服务器实现的、适用于该资源的可选特性的任何头字段（例如，Allow），可能包括本规范没有定义的扩展。响应主体（如果有的话）也应该包括关于通信选项的信息。这种主体的格式没有被本规范定义，但可能被 HTTP 的未来扩展所定义。内容协商可能被用来选择适当的响应格式。如果不包括响应主体，响应必须包括一个字段值为 “0” 的 Content-Length 字段。

Max-Forwards 请求头字段可以用来针对请求链中的一个特定代理。当代理机构收到允许请求转发的绝对 URI 上的 OPTIONS 请求时，该代理机构必须检查 Max-Forwards 字段。如果 Max-Forwards 字段的值是零（”0”），代理机构必须不转发该消息；相反，代理机构应该用它自己的通信选项来响应。如果 Max-Forwards 字段值是一个大于 0 的整数，代理机构在转发请求时必须递减该字段值。如果请求中没有 Max-Forwards 字段，那么转发的请求必须不包括 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”。有条件的 GET 方法要求仅在有条件的头字段所描述的情况下传输实体。有条件的 GET 方法是为了减少不必要的网络使用，它允许缓存的实体被刷新，而不需要多次请求或传输客户端已经持有的数据。

如果请求消息包括一个 Range 头字段，GET 方法的语义就会变成 “部分 GET”。部分 GET 请求只传输实体的一部分，如 14.35 节所述。部分 GET 方法是为了减少不必要的网络使用，它允许部分检索的实体被完成，而不传输客户机已经持有的数据。

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

有关用于表单时的安全注意事项，请参阅第 15.1.3 节。

9.4 HEAD

HEAD 方法与 GET 相同，只是服务器必须不在响应中返回消息体。响应 HEAD 请求的 HTTP 头中包含的元信息应该与响应 GET 请求时发送的信息相同。这种方法可以用来获取请求所暗示的实体的元信息，而不需要传输实体本身。这种方法经常被用于测试超文本链接的有效性、可访问性和最近的修改。

对 HEAD 请求的响应可能是可缓存的，即响应中包含的信息可能被用来更新该资源中先前缓存的实体。如果新的字段值表明缓存的实体与当前的实体不同（如 Content-Length、Content-MD5、ETag 或 Last-Modified 的变化所表明的），那么缓存必须将缓存条目视为过期。

9.5 POST

POST 方法用于请求源服务器接受请求中所包含的实体作为 Request-URI 在 Request-Line 中标识的资源的一个新的下级。POST 被设计成允许一个统一的方法来涵盖以下功能：

• 对现有资源进行注释。
• 向公告板、新闻组、邮件列表或类似的文章组发布信息。
• 提供一个数据块，如提交表格的结果，给一个数据处理过程。
• 通过附加操作扩展一个数据库。

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

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

如果在源服务器上已经创建了一个资源，那么响应应该是 201（Created），并包含一个描述请求状态的实体，并提及新资源，以及一个 Location 头（见第 14.30 节）。

对这种方法的响应是不可缓存的，除非该响应包括适当的 Cache-Control 或 Expires 字段。然而，303（See Other）响应可以用来指导用户代理检索一个可缓存的资源。

POST 请求必须遵守第 8.2 节中规定的消息传输要求。

有关安全注意事项，请参阅第 15.1.3 节。

9.6 PUT

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

如果请求通过了缓存，并且 Request-URI 标识了一个或多个当前缓存的实体，那么这些条目应该被视为过时的。对这种方法的响应是不可缓存的。

POST 和 PUT 请求的根本区别体现在 Request-URI 的不同含义上。POST 请求中的 URI 标识了将处理所附实体的资源。该资源可能是一个接受数据的过程，一个通往其他协议的网关，或者一个接受注释的独立实体。相反，PUT 请求中的 URI 标识了与请求一起被包围的实体—用户代理知道打算使用什么 URI，并且服务器不得试图将请求应用到其他资源。如果服务器希望将请求应用于不同的 URI，它必须发送一个 301（Moved Permanently）响应；然后用户代理可以自己决定是否重定向该请求。

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

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

PUT 请求必须遵守第 8.2 节中规定的消息传输要求。

除非对特定的实体头另有规定，PUT 请求中的实体头应该被应用于由 PUT 创建或修改的资源。

9.7 DELETE

DELETE 方法要求源服务器删除由 Request-URI 标识的资源。这个方法可能会被源服务器上的人工干预（或其他手段）所覆盖。即使从源服务器返回的状态码表明该操作已成功完成，也不能保证客户机已经执行了该操作。然而，服务器不应表示成功，除非在给出响应时，它打算删除该资源或将其移到一个不可访问的位置。

如果响应包括一个描述状态的实体，则成功的响应应该是 200（OK）；如果行动尚未实施，则是 202（Accepted）；如果行动已经实施但响应不包括一个实体，则是204（No Content）。

如果请求通过了缓存，并且 Request-URI 标识了一个或多个当前缓存的实体，那么这些条目应该被视为过时的。对这种方法的响应是不可缓存的。

9.8 TRACE

TRACE 方法被用来调用一个远程的、应用层的请求消息的循环。请求的最终接收者应该将收到的消息作为200(OK) 响应的实体主体反馈给客户端。最终接收者是源服务器或在请求中收到最大转发值为 0 的第一个代理或网关（见第 14.31 节）。TRACE 请求必须不包括实体。

TRACE 允许客户端看到在请求链的另一端收到什么，并将这些数据用于测试或诊断信息。Via 头字段的值（第 14.45 节）特别有意义，因为它可以作为请求链的一个跟踪。使用 Max-Forwards 头字段允许客户端限制请求链的长度，这对于测试无限循环转发消息的代理链很有用。

如果请求是有效的，响应应该在实体主体中包含整个请求信息，其内容类型为 “message/http”。对这个方法的响应必须不被缓存。

9.9 CONNECT

本规范将方法名称 CONNECT 保留给可以动态切换为隧道的代理使用（例如 SSL 隧道 [44]）。