超文本传输​​协议 - HTTP / 1.1（Hypertext Transfer Protocol -- HTTP/1.1）之方法定义（Method Definitions）

9方法定义

下面定义了HTTP / 1.1的一组常用方法。尽管可以扩展这个集合，但是另外的方法不能假定为单独扩展的客户端和服务器共享相同的语义。

主机请求头域（14.23节）必须伴随所有的HTTP / 1.1请求。

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方法代表请求关于在请求/响应链上可用的通信选项的信息，该请求/响应链由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”的内容长度字段。

Max-Forwards请求头域可以用来在请求链中定位一个特定的代理。当一个代理收到一个允许请求转发的absoluteURI的OPTIONS请求时，代理务必检查一个Max-Forwards字段。如果Max-Forwards字段值为零（“0”），则代理不能转发该消息; 相反，代理应该用自己的通信选项进行响应。如果Max-Forwards字段值是一个大于零的整数，那么代理在转发请求时必须递减字段值。如果请求中没有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-Line中Request-URI标识的资源的新下属。POST被设计为允许统一的方法来覆盖以下功能：

      - 现有资源的注释;

      - 发布信息到公告栏，新闻组，邮件列表，
        或类似的一组文章;

      - 提供一个数据块，比如提交一个
        形式，到数据处理过程;

      - 通过追加操作扩展数据库。

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

POST方法执行的操作可能不会导致可以通过URI标识的资源。在这种情况下，根据响应是否包含描述结果的实体，200（OK）或204（无内容）是适当的响应状态。

如果源服务器上已经创建了一个资源，那么响应应该是201（创建），并且包含一个描述请求状态的实体，并引用新资源和一个位置标题（见14.30节）。

除非响应包含适当的Cache-Control或Expires头字段，否则对此方法的响应不可缓存。但是，303（请参阅其他）响应可用于指导用户代理检索可缓存资源。

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

出于安全考虑， 请参阅第15.1.3节。

9.6 PUT

PUT方法要求封闭的实体存储在提供的Request-URI下。如果Request-URI引用一个已经存在的资源，封闭的实体应该被认为是驻留在原始服务器上的修改版本。如果Request-URI不指向现有资源，并且该URI能够被请求用户代理定义为新资源，则源服务器可以使用该URI创建资源。如果创建了新资源，源服务器必须通过201（创建）响应通知用户代理。如果现有资源被修改，则应发送200（OK）或204（无内容）响应代码以指示成功完成请求。如果资源不能用Request-URI创建或修改，应该给出一个适当的错误响应来反映问题的性质。实体的接收者不能忽略任何不理解或实现的Content- *（例如Content-Range）头，在这种情况下必须返回一个501（未实现）响应。

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

POST和PUT请求之间的根本区别反映在Request-URI的不同含义中。POST请求中的URI标识将处理封闭实体的资源。该资源可能是数据接受过程，某个其他协议的入口，也可能是接受注释的单独实体。相比之下，PUT请求中的URI标识了请求所包含的实体 - 用户代理知道哪个URI是预期的，服务器不能尝试将请求应用到其他资源。如果服务器希望将请求应用于不同的URI，

它必须发送301（永久移动）响应; 用户代理可以自行决定是否重定向请求。

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

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

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

除非特定的实体头文件另外指定，否则PUT请求中的实体头文件应该被应用到由PUT创建或修改的资源。

9.7删除

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

如果响应包括描述状态的实体，则成功的响应应该是200（OK），如果该操作尚未实施，则成功响应202（接受），如果该操作已经被实施，则响应不包括204（无内容）一个实体。

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

9.8 TRACE

TRACE方法用于调用请求消息的远程应用层环回。请求的最终接收者应该将接收到的消息反映为200（OK）响应的实体主体。最后的收件人是要么

原始服务器或第一个代理或网关在请求中接收Max-Forwards值为零（0）（请参阅14.31节）。一个TRACE请求不能包含一个实体。

TRACE允许客户端查看请求链另一端正在接收的内容，并将该数据用于测试或诊断信息。Via头域的值（14.45节）特别引人关注，因为它充当请求链的轨迹。使用Max-Forwards头字段允许客户端限制请求链的长度，这对于在无限循环中测试代理转发消息链是有用的。

如果请求是有效的，那么响应应该包含entity-body中的整个请求消息，其内容类型为“message / http”。对此方法的响应不能被缓存。

9.9连接

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

注：原文来自w3c ,https://www.w3.org/Protocols/rfc2616/rfc2616.html