跳到主要内容

9. 方法定义 (Method Definitions)

9 Method Definitions

HTTP/1.1 的常用 method 集合定义如下. 虽然该集合可以扩展, 但对于分别扩展的 client 和 server, 不能假定额外 method 共享相同语义.

Host request-header field (第 14.23 节) MUST 随所有 HTTP/1.1 request 一起发送.

9.1 安全和幂等方法

9.1.1 安全方法

实现者应知道, 软件代表用户在 Internet 上进行交互, 因此应谨慎允许用户意识到他们可能采取的任何操作, 这些操作可能对自己或他人具有意外意义.

特别是, 已经建立的惯例是 GET 和 HEAD method SHOULD NOT 具有检索以外动作的意义. 这些 method 应视为 "safe". 这允许 user agent 以特殊方式表示其他 method, 如 POST, PUT 和 DELETE, 从而让用户知道正在请求一个可能不安全的操作.

当然, 无法确保 server 不会因执行 GET request 而产生 side-effect; 事实上, 某些动态 resource 把这视为一种功能. 这里的重要区别在于用户并未请求这些 side-effect, 因而不能要求用户对此负责.

9.1.2 幂等方法

method 还可以具有 "idempotence" 属性, 即 (除错误或过期问题外) N > 0 个相同 request 的 side-effect 与单个 request 相同. GET, HEAD, PUT 和 DELETE method 具有该属性. 此外, OPTIONS 和 TRACE method SHOULD NOT 具有 side effect, 因而本质上是幂等的.

但是, 即使某个序列中执行的所有 method 都是幂等的, 多个 request 组成的序列也可能是非幂等的. (如果整个序列的一次执行总是产生一个不会因重新执行该序列的全部或部分而改变的结果, 则该序列是幂等的.) 例如, 如果某序列的结果依赖于同一序列后续会修改的值, 则该序列是非幂等的.

按定义, 从不产生 side effect 的序列是幂等的 (前提是在同一 resource 集合上没有并发操作正在执行).

9.2 OPTIONS

OPTIONS method 表示请求关于 Request-URI 所标识 request/response 链上可用通信选项的信息. 该 method 允许 client 确定与某个 resource 关联的选项和/或要求, 或 server 的能力, 而不暗示 resource 操作或启动 resource 检索.

对此 method 的 response 不可缓存.

如果 OPTIONS request 包含 entity-body (由 Content-Length 或 Transfer-Encoding 的存在表示), 则 MUST 由 Content-Type field 指明 media type. 虽然本规范没有定义此类 body 的任何用途, HTTP 的未来扩展可能使用 OPTIONS body 对 server 进行更详细查询. 不支持此类扩展的 server MAY 丢弃 request body.

如果 Request-URI 是星号 (""), OPTIONS request 旨在适用于 server 整体而非特定 resource. 由于 server 的通信选项通常取决于 resource, "" request 只适合作为 "ping" 或 "no-op" 类型的 method; 它除了允许 client 测试 server 能力外不做任何事. 例如, 这可用于测试某个 proxy 是否符合 HTTP/1.1 (或缺乏这种符合性).

如果 Request-URI 不是星号, OPTIONS request 只适用于与该 resource 通信时可用的选项.

200 response SHOULD 包含任何指示 server 实现且适用于该 resource 的可选功能的 header field (例如 Allow), 可能包括本规范未定义的扩展. response body (如果有) SHOULD 也包含关于通信选项的信息. 此类 body 的格式不由本规范定义, 但可能由 HTTP 未来扩展定义.

MAY 使用 content negotiation 来选择适当 response 格式. 如果不包含 response body, response MUST 包含 field-value 为 "0" 的 Content-Length field.

Max-Forwards request-header field MAY 用于定位 request 链中的特定 proxy. 当 proxy 收到针对 absoluteURI 且允许 request 转发的 OPTIONS request 时, proxy MUST 检查 Max-Forwards field. 如果 Max-Forwards field-value 为零 ("0"), proxy MUST NOT 转发 message; 相反, proxy SHOULD 以自己的通信选项响应. 如果 Max-Forwards field-value 是大于零的整数, proxy 在转发 request 时 MUST 递减该 field-value. 如果 request 中不存在 Max-Forwards field, 则被转发的 request MUST NOT 包含 Max-Forwards field.

9.3 GET

GET method 表示检索 Request-URI 所标识的任何信息 (以 entity 形式). 如果 Request-URI 引用的是一个产生数据的过程, 则 response 中作为 entity 返回的应是产生的数据, 而不是该过程的源文本, 除非该文本恰好就是该过程的输出.

如果 request message 包含 If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match 或 If-Range header field, GET method 的语义变为 "conditional GET". conditional GET method 请求仅在 conditional header field 所描述的条件下传输 entity. conditional GET method 旨在减少不必要网络使用, 允许刷新已缓存 entity, 而不需要多个 request 或传输 client 已持有的数据.

如果 request message 包含 Range header field, GET method 的语义变为 "partial GET". partial GET 请求只传输 entity 的一部分, 如第 14.35 节所述. partial GET method 旨在减少不必要网络使用, 允许完成部分检索的 entity, 而不传输 client 已持有的数据.

当且仅当 GET request 的 response 满足第 13 节所述 HTTP caching 要求时, 该 response 才可缓存.

用于表单时的安全考虑见第 15.1.3 节.

9.4 HEAD

HEAD method 与 GET 相同, 只是 server MUST NOT 在 response 中返回 message-body. 对 HEAD request 的 response 中 HTTP header 包含的元信息 SHOULD 与对 GET request 发送的信息相同. 该 method 可用于获取 request 所隐含 entity 的元信息, 而不传输 entity-body 本身. 该 method 常用于测试 hypertext link 的有效性, 可访问性和最近修改情况.

对 HEAD request 的 response MAY 是可缓存的, 意味着 response 中包含的信息 MAY 用于更新来自该 resource 的先前缓存 entity. 如果新的 field value 表示缓存 entity 不同于当前 entity (这可由 Content-Length, Content-MD5, ETag 或 Last-Modified 变化指示), 则 cache MUST 将该 cache entry 视为 stale.

9.5 POST

POST method 用于请求 origin server 接受 request 中包含的 entity, 将其作为 Request-Line 中 Request-URI 所标识 resource 的新 subordinate. POST 设计为允许一个统一 method 覆盖以下功能:

  - 对现有 resource 的注释;

  - 向 bulletin board, newsgroup, mailing list 或类似文章组投递 message;

  - 向数据处理过程提供一块数据, 例如提交表单的结果;

  - 通过 append 操作扩展数据库.

POST method 实际执行的功能由 server 确定, 且通常依赖 Request-URI. posted entity 从属于该 URI, 其方式类似于文件从属于包含它的目录, news article 从属于其投递到的 newsgroup, 或记录从属于数据库.

POST method 执行的动作可能不会产生可由 URI 标识的 resource. 在这种情况下, 适当的 response status 是 200 (OK) 或 204 (No Content), 具体取决于 response 是否包含描述结果的 entity.

如果在 origin server 上创建了 resource, response SHOULD 为 201 (Created), 并包含一个描述 request 状态且引用新 resource 的 entity, 以及一个 Location header (见第 14.30 节).

对此 method 的 response 不可缓存, 除非 response 包含适当的 Cache-Control 或 Expires header field. 但是, 可使用 303 (See Other) response 指示 user agent 检索一个可缓存 resource.

POST request MUST 遵守第 8.2 节规定的 message transmission requirements.

安全考虑见第 15.1.3 节.

9.6 PUT

PUT method 请求将所包含 entity 存储在给定 Request-URI 之下. 如果 Request-URI 引用已经存在的 resource, 则所包含 entity SHOULD 被视为 origin server 上现有 entity 的修改版本. 如果 Request-URI 未指向现有 resource, 且该 URI 能够由请求 user agent 定义为新 resource, origin server 可以用该 URI 创建 resource. 如果创建了新 resource, origin server MUST 通过 201 (Created) response 通知 user agent. 如果修改了现有 resource, SHOULD 发送 200 (OK) 或 204 (No Content) response code 来表示 request 成功完成. 如果无法用该 Request-URI 创建或修改 resource, SHOULD 给出反映问题性质的适当 error response. entity 的 recipient MUST NOT 忽略任何自己不理解或未实现的 Content-* (例如 Content-Range) header, 并且在此类情况下 MUST 返回 501 (Not Implemented) response.

如果 request 经过 cache, 且 Request-URI 标识一个或多个当前已缓存 entity, 这些 entry SHOULD 被视为 stale. 对此 method 的 response 不可缓存.

POST 和 PUT request 的根本区别体现在 Request-URI 的不同含义中. POST request 中的 URI 标识将处理所包含 entity 的 resource. 该 resource 可能是一个接受数据的过程, 到某个其他协议的 gateway, 或接受注释的独立 entity. 相比之下, PUT request 中的 URI 标识随 request 包含的 entity -- user agent 知道目标 URI 是什么, server MUST NOT 试图把 request 应用到某个其他 resource. 如果 server 希望 request 应用于不同 URI,

它 MUST 发送 301 (Moved Permanently) response; 然后 user agent MAY 自行决定是否重定向 request.

单个 resource MAY 由多个不同 URI 标识. 例如, 一篇 article 可能有一个用于标识 "the current version" 的 URI, 它不同于标识每个特定版本的 URI. 在这种情况下, 对通用 URI 的 PUT request 可能导致 origin server 定义若干其他 URI.

HTTP/1.1 不定义 PUT method 如何影响 origin server 的状态.

PUT request MUST 遵守第 8.2 节规定的 message transmission requirements.

除非特定 entity-header 另有规定, PUT request 中的 entity-header SHOULD 应用于 PUT 创建或修改的 resource.

9.7 DELETE

DELETE method 请求 origin server 删除 Request-URI 所标识的 resource. 该 method MAY 被 origin server 上的人工干预 (或其他方式) 覆盖. 即使 origin server 返回的 status code 表示动作已成功完成, client 也不能保证该操作已经执行. 但是, 除非 server 在给出 response 时打算删除该 resource 或将其移动到不可访问位置, 否则 SHOULD NOT 表示成功.

如果 response 包含描述 status 的 entity, 成功 response SHOULD 为 200 (OK); 如果动作尚未执行, SHOULD 为 202 (Accepted); 如果动作已执行但 response 不包含 entity, SHOULD 为 204 (No Content).

如果 request 经过 cache, 且 Request-URI 标识一个或多个当前已缓存 entity, 这些 entry SHOULD 被视为 stale. 对此 method 的 response 不可缓存.

9.8 TRACE

TRACE method 用于调用 request message 的远程应用层 loop-back. request 的最终 recipient SHOULD 把收到的 message 作为 200 (OK) response 的 entity-body 反射回 client. 最终 recipient 是 origin server, 或第一个在 request 中收到 Max-Forwards 值为零 (0) 的 proxy 或 gateway (见第 14.31 节). TRACE request MUST NOT 包含 entity.

TRACE 允许 client 看到 request 链另一端收到的内容, 并将该数据用于测试或诊断信息. Via header field (第 14.45 节) 的值特别有用, 因为它充当 request 链的 trace. 使用 Max-Forwards header field 允许 client 限制 request 链长度, 这对测试会以无限循环转发 message 的 proxy 链很有用.

如果 request 有效, response SHOULD 在 entity-body 中包含完整 request message, 且 Content-Type 为 "message/http". 对此 method 的 response MUST NOT 被缓存.

9.9 CONNECT

本规范保留 method name CONNECT, 用于可动态切换为 tunnel 的 proxy (例如 SSL tunneling [44]).

最后于 更新