9. 方法

9.1. 概述

请求方法 token 是请求语义的主要来源; 它指示客户端发出该请求的目的, 以及客户端期望什么作为成功结果.

当请求中存在某些头字段时, 如果这些附加语义不与方法冲突, 请求方法的语义可以由这些头字段的语义进一步专门化. 例如, 客户端可以发送条件请求头字段 (Section 13.1), 使请求动作以目标资源当前状态为条件.

HTTP 被设计为可用作分布式对象系统的接口. 请求方法调用一个要应用于目标资源的动作, 方式非常类似于远程方法调用可被发送到某个已标识对象.

method = token

方法 token 区分大小写, 因为它可能被用作通往基于对象且方法名区分大小写系统的网关. 按照约定, 标准化方法使用全大写 US-ASCII 字母定义.

与分布式对象不同, HTTP 中的标准化请求方法不是资源特定的, 因为统一接口为基于网络的系统提供了更好的可见性和复用 [REST].一旦定义, 标准化方法在应用于任何资源时都应具有相同语义, 尽管每个资源自行决定这些语义是否被实现或允许.

本规范定义了若干 HTTP 中常用的标准化方法, 如下表概述.

Method Name	描述	章节
GET	传输目标资源的当前表示.	9.3.1
HEAD	与 GET 相同, 但不传输响应内容.	9.3.2
POST	对请求内容执行资源特定处理.	9.3.3
PUT	用请求内容替换目标资源的所有当前表示.	9.3.4
DELETE	移除目标资源的所有当前表示.	9.3.5
CONNECT	建立到目标资源所标识服务器的隧道.	9.3.6
OPTIONS	描述目标资源的通信选项.	9.3.7
TRACE	沿目标资源路径执行消息回环测试.	9.3.8

所有通用服务器必须支持 GET 和 HEAD 方法. 所有其他方法都是可选的.

目标资源允许的方法集合可以列在 Allow 头字段 (Section 10.2.1) 中. 然而, 允许的方法集合可以动态变化. 源服务器收到未识别或未实现的请求方法时, 应以 501 (Not Implemented) 状态码响应. 源服务器收到已识别且已实现, 但不允许用于目标资源的请求方法时, 应以 405 (Method Not Allowed) 状态码响应.

已有其他超出本规范范围的方法被指定用于 HTTP. 所有此类方法都应注册到 "Hypertext Transfer Protocol (HTTP) Method Registry", 如 Section 16.1 所述.

9.2. 通用方法属性

9.2.1. 安全方法

如果请求方法所定义的语义本质上是只读的, 则认为该方法是 "安全的" (safe); 即客户端并未请求, 也不期望因把安全方法应用于目标资源而在源服务器上发生任何状态变化. 同样, 合理使用安全方法不预期会给源服务器造成任何损害, 财产损失或异常负担.

安全方法的这个定义并不阻止实现在调用安全方法时包含潜在有害, 并非完全只读或会造成副作用的行为. 然而, 重要的是客户端没有请求该附加行为, 也不能为其负责. 例如, 大多数服务器会在每个响应完成时把请求信息追加到访问日志文件中, 无论使用什么方法; 即使日志存储可能变满并导致服务器失败, 这仍被认为是安全的. 同样, 通过选择 Web 上广告而发起的安全请求, 常有向广告账户计费的副作用.

在本规范定义的请求方法中, GET, HEAD, OPTIONS 和 TRACE 方法被定义为安全的.

区分安全和不安全方法的目的是允许自动检索过程 (spiders) 和缓存性能优化 (pre-fetching) 在不用担心造成损害的情况下工作. 此外, 这允许用户代理在处理潜在不受信任内容时, 对不安全方法的自动使用施加适当约束.

用户代理在向用户呈现潜在动作时应区分安全和不安全方法, 使用户在请求不安全动作之前能够知晓.

当资源被构造为目标 URI 内参数具有选择动作效果时, 资源所有者有责任确保该动作与请求方法语义一致. 例如, 基于 Web 的内容编辑软件常在查询参数中使用动作, 如 "page?do=delete".如果此类资源的目的是执行不安全动作, 则当使用安全请求方法访问该资源时, 资源所有者必须禁用或不允许该动作. 否则, 当自动化过程为了链接维护, 预取, 构建搜索索引等目的对每个 URI 引用执行 GET 时, 会产生不幸的副作用.

9.2.2. 幂等方法

如果使用某请求方法的多个相同请求对服务器的预期效果与单个此类请求的效果相同, 则认为该请求方法是 "幂等的" (idempotent). 在本规范定义的请求方法中, PUT, DELETE 和安全请求方法是幂等的.

与安全的定义一样, 幂等属性只适用于用户所请求的内容; 服务器可以为每个请求单独记录日志, 保留修订控制历史, 或为每个幂等请求实现其他非幂等副作用.

幂等方法之所以被区分, 是因为如果客户端在能够读取服务器响应之前发生通信失败, 请求可以被自动重复. 例如, 如果客户端发送 PUT 请求且底层连接在收到任何响应之前关闭, 则客户端可以建立新连接并重试该幂等请求. 它知道重复该请求会具有相同预期效果, 即使原始请求已经成功, 尽管响应可能不同.

除非客户端有办法知道请求语义实际上是幂等的 (无论方法如何), 或有办法检测原始请求从未被应用, 否则客户端不应自动重试使用非幂等方法的请求.

例如, 如果用户代理知道 (通过设计或配置) 该资源的请求是安全的, 则可以自动重复 POST 请求. 同样, 专门设计用于操作版本控制仓库的用户代理, 可能能够在连接失败后检查目标资源修订, 回退或修复已部分应用的任何更改, 然后自动重试失败请求, 从而从部分失败条件中恢复.

有些客户端采用风险更高的方法, 尝试猜测何时可以自动重试. 例如, 如果底层传输连接在收到响应任何部分之前关闭, 客户端可能自动重试 POST 请求, 尤其是在使用空闲持久连接时.

代理不得自动重试非幂等请求. 客户端不应自动重试已经失败的自动重试.

9.2.3. 方法和缓存

为了让缓存存储并使用响应, 关联方法需要显式允许缓存, 并详细说明在什么条件下响应可用于满足后续请求; 未这样做的方法定义不能被缓存. 附加要求见 [CACHING].

本规范为 GET, HEAD 和 POST 定义缓存语义, 尽管绝大多数缓存实现只支持 GET 和 HEAD.

9.3. 方法定义

9.3.1. GET

GET 方法请求传输目标资源的当前选定表示. 成功响应反映目标 URI 所标识的 "同一性" 品质 ([URI] Section 1.2.2). 因此, 通过 HTTP 检索可标识信息通常是通过对某个标识符发起 GET 请求完成的, 该标识符关联着在 200 (OK) 响应中提供该信息的可能性.

GET 是信息检索的主要机制, 也是几乎所有性能优化的焦点. 为每个重要资源生成 URI 的应用可以从这些优化中受益, 同时允许其他应用复用它们, 形成推动 Web 进一步扩展的网络效应.

人们很容易把资源标识符想成远程文件系统路径名, 把表示想成这类文件内容的副本. 事实上, 许多资源确实如此实现 (相关安全考虑见 Section 17.3). 然而, 实践中并不存在这种限制.

资源的 HTTP 接口同样可能被实现为内容对象树, 各种数据库记录的程序化视图, 或通往其他信息系统的网关. 即使 URI 映射机制绑定到文件系统, 源服务器也可能被配置为以请求作为输入执行文件并把输出作为表示发送, 而不是直接传输文件. 无论如何, 只有源服务器需要知道其每个资源标识符如何对应到实现, 以及该实现如何选择并发送目标资源的当前表示.

客户端可以通过在请求中发送 Range 头字段 (Section 14.2), 把 GET 语义改为 "范围请求" (range request), 即只请求传输选定表示的某些部分.

虽然请求消息定帧独立于所用方法, 但 GET 请求中收到的内容没有通用定义语义, 不能改变请求的含义或目标, 并且由于其作为请求走私攻击的潜力, 可能导致某些实现拒绝请求并关闭连接 ([HTTP/1.1] Section 11.2). 除非请求直接发往源服务器, 且该源服务器此前已在带内或带外指示此类请求有目的且将得到充分支持, 否则客户端不应在 GET 请求中生成内容. 源服务器不应依赖私有协议来接收内容, 因为 HTTP 通信参与者常不知道请求链上的中介.

GET 请求的响应是可缓存的; 除非 Cache-Control 头字段 ([CACHING] Section 5.2) 另有指示, 缓存可以使用它来满足后续 GET 和 HEAD 请求.

当信息检索使用一种根据用户提供信息构造目标 URI 的机制执行时, 例如使用 GET 的表单查询字段, 可能会提供不适合在 URI 中披露的潜在敏感数据 (见 Section 17.9). 在某些情况下, 可以过滤或转换数据, 使其不会泄露此类信息. 在其他情况下, 尤其是缓存响应没有收益时, 使用 POST 方法 (Section 9.3.3) 而不是 GET, 可以在请求内容中传输此类信息, 而不是在目标 URI 内传输.

9.3.2. HEAD

HEAD 方法与 GET 相同, 只是服务器不得在响应中发送内容. HEAD 用于在不传输表示数据的情况下获得选定表示的元数据, 常用于测试超文本链接或查找最近修改.

服务器对 HEAD 请求的响应应发送与对 GET 请求响应本应发送的相同头字段. 然而, 服务器可以省略那些只有在生成内容时才能确定值的头字段. 例如, 有些服务器会缓冲对 GET 的动态响应, 直到生成最小量数据, 以便更高效地定界小响应或对内容选择做出较晚决策. 此类 GET 响应可能包含 Content-Length 和 Vary 字段, 例如, 这些字段不会在 HEAD 响应中生成. 由于 HEAD 通常出于效率目的被请求, 这些小不一致被认为优于为 HEAD 请求生成并丢弃内容.

虽然请求消息定帧独立于所用方法, 但 HEAD 请求中收到的内容没有通用定义语义, 不能改变请求的含义或目标, 并且由于其作为请求走私攻击的潜力, 可能导致某些实现拒绝请求并关闭连接 ([HTTP/1.1] Section 11.2). 除非请求直接发往源服务器, 且该源服务器此前已在带内或带外指示此类请求有目的且将得到充分支持, 否则客户端不应在 HEAD 请求中生成内容. 源服务器不应依赖私有协议来接收内容, 因为 HTTP 通信参与者常不知道请求链上的中介.

HEAD 请求的响应是可缓存的; 除非 Cache-Control 头字段 ([CACHING] Section 5.2) 另有指示, 缓存可以使用它来满足后续 HEAD 请求. HEAD 响应还可能影响先前缓存的 GET 响应; 见 [CACHING] Section 4.3.5.

9.3.3. POST

POST 方法请求目标资源按其自身特定语义处理请求中封装的表示. 例如, POST 用于以下功能 (以及其他功能):

• 向数据处理过程提供一个数据块, 如 HTML 表单中输入的字段;
• 向公告板, 新闻组, 邮件列表, 博客或类似文章组发布消息;
• 创建尚未由源服务器标识的新资源; 以及
• 向资源的现有表示追加数据.

源服务器根据处理 POST 请求的结果选择适当状态码来指示响应语义; 本规范定义的几乎所有状态码都可能在对 POST 的响应中收到 (例外是 206 (Partial Content),304 (Not Modified) 和 416 (Range Not Satisfiable)).

如果源服务器由于成功处理 POST 请求而创建了一个或多个资源, 则源服务器应发送 201 (Created) 响应, 其中包含 Location 头字段 (Section 10.2.2) 以提供所创建主要资源的标识符, 并包含描述请求状态且引用新资源的表示.

POST 请求的响应只有在包含显式新鲜度信息 (见 [CACHING] Section 4.2.1) 和 Content-Location 头字段 (Section 8.7), 且该字段与 POST 的目标 URI 值相同时才可缓存. 缓存的 POST 响应可复用来满足后续 GET 或 HEAD 请求. 相反, POST 请求不能由缓存的 POST 响应满足, 因为 POST 可能不安全; 见 [CACHING] Section 4.

如果处理 POST 的结果等价于某个现有资源的表示, 源服务器可以通过发送 303 (See Other) 响应并在 Location 字段中放入现有资源标识符, 将用户代理重定向到该资源. 这样做的好处是为用户代理提供资源标识符, 并通过更适合共享缓存的方法传输表示; 代价是如果用户代理尚未缓存该表示, 会增加一次额外请求.

9.3.4. PUT

PUT 方法请求用请求消息内容中封装的表示所定义状态来创建或替换目标资源状态. 给定表示的成功 PUT 暗示随后对同一目标资源的 GET 会导致在 200 (OK) 响应中发送等价表示. 然而, 无法保证这种状态变化一定可观察, 因为在任何后续 GET 到达之前, 目标资源可能被其他用户代理并行操作, 或可能受源服务器动态处理影响. 成功响应只意味着用户代理意图在源服务器处理时已达成.

如果目标资源没有当前表示且 PUT 成功创建了一个, 则源服务器必须通过发送 201 (Created) 响应告知用户代理. 如果目标资源已有当前表示, 且该表示已按照封装表示的状态成功修改, 则源服务器必须发送 200 (OK) 或 204 (No Content) 响应来指示请求成功完成.

源服务器应验证 PUT 表示是否与其为目标资源配置的约束一致. 例如, 如果源服务器根据 URI 确定资源表示元数据, 则源服务器需要确保成功 PUT 请求中收到的内容与该元数据一致. 当 PUT 表示与目标资源不一致时, 源服务器应通过转换表示或改变资源配置使它们一致, 或以适当错误消息响应, 其中包含足够信息说明该表示为何不合适. 建议使用 409 (Conflict) 或 415 (Unsupported Media Type) 状态码, 后者专门用于 Content-Type 值约束.

例如, 如果目标资源被配置为始终具有 Content-Type "text/html", 而被 PUT 的表示具有 Content-Type "image/jpeg", 源服务器应执行以下之一:

a. 重新配置目标资源以反映新媒体类型; b. 在把 PUT 表示保存为新资源状态之前, 将其转换为与资源一致的格式; 或者, c. 以 415 (Unsupported Media Type) 响应拒绝请求, 指示目标资源限于 "text/html", 也许还包含指向适合新表示的不同资源的链接.

HTTP 并未定义 PUT 方法如何影响源服务器状态, 除了用户代理请求意图和源服务器响应语义所能表达的内容. 除通过 HTTP 提供的接口外, 它没有以任何意义定义资源可能是什么. 它没有定义资源状态如何 "存储", 也没有定义这种存储如何因资源状态变化而改变, 或源服务器如何把资源状态转换为表示. 一般而言, 资源接口背后的所有实现细节都由服务器有意隐藏.

这也扩展到源服务器如何决定把标识符关联到资源. 源服务器独自负责把目标 URI 映射到资源, 因而也独自负责该资源的创建, 修改或销毁. 目标 URI 形式与源服务器管理的任何内部状态之间没有必需关系, 这使 URI 对任何不了解服务器实现细节的客户端都是不透明的.

除非请求的表示数据未经任何转换应用于内容而保存 (即资源的新表示数据与 PUT 请求中收到的内容相同), 且验证器字段值反映新表示, 否则源服务器不得在对 PUT 的成功响应中发送验证器字段 (Section 8.8), 如 ETag 或 Last-Modified 字段. 此要求使用户代理知道其发送 (并保留在内存中) 的表示就是 PUT 的结果, 因而无需再次从源服务器检索. 响应中收到的新验证器可用于未来条件请求, 以防止意外覆盖 (Section 13.1).

POST 和 PUT 方法的根本区别体现在封装表示的不同意图上. POST 请求中的目标资源意图按资源自身语义处理封装表示, 而 PUT 请求中的封装表示被定义为替换目标资源状态. 因此, PUT 的意图是幂等的, 并且对中介可见, 尽管确切效果只有源服务器知道.

正确解释 PUT 请求预设用户代理知道期望的目标资源. 代表客户端在收到状态变更请求后选择适当 URI 的服务, 应使用 POST 方法而不是 PUT 实现. 如果源服务器不会把请求的 PUT 状态变化应用到目标资源, 而是希望将其应用到不同资源, 例如资源已移动到不同 URI 时, 则源服务器必须发送适当的 3xx (Redirection) 响应; 用户代理随后可以自行决定是否重定向请求.

应用于目标资源的 PUT 请求可能对其他资源产生副作用. 例如, 一篇文章可能有一个用于标识 "当前版本" (一个资源) 的 URI, 它不同于标识每个特定版本的 URI (这些不同资源在某一时刻与当前版本资源共享相同状态). 因此, 对 "当前版本" URI 的成功 PUT 请求除了改变目标资源状态外, 还可能创建新版本资源, 并可能导致在相关资源之间添加链接.

允许对给定目标资源使用 PUT 的源服务器, 对包含 Content-Range 头字段 (Section 14.4) 的 PUT 请求必须发送 400 (Bad Request) 响应, 因为内容可能不完整. 可以通过以一个单独标识的资源为目标来进行部分内容更新, 该资源的状态与较大资源的一部分重叠; 或使用专门为部分更新定义的不同方法 (例如 [RFC5789] 中定义的 PATCH 方法).

PUT 请求的响应不可缓存. 如果成功 PUT 请求经过某个缓存, 且该缓存为目标 URI 存有一个或多个响应, 则这些已存储响应将被失效 (见 [CACHING] Section 4.4).

9.3.5. DELETE

DELETE 方法请求源服务器移除目标资源与其当前功能之间的关联. 实际上, 此方法类似 UNIX 中的 rm 命令: 它表达的是对源服务器 URI 映射的删除操作, 而不是期望先前关联的信息被删除.

如果目标资源有一个或多个当前表示, 它们可能会也可能不会被源服务器销毁, 关联存储也可能会或可能不会被回收, 这完全取决于资源性质及源服务器对其的实现 (超出本规范范围). 同样, DELETE 的结果可能需要停用或归档资源的其他实现方面, 如数据库或网关连接. 一般假定源服务器只会允许对其具有规定删除机制的资源执行 DELETE.

允许 DELETE 方法的资源相对较少, 其主要用途是远程创作环境, 在该环境中用户对其效果有一定方向. 例如, 先前使用 PUT 请求创建的资源, 或在对 POST 请求的 201 (Created) 响应后通过 Location 头字段标识的资源, 可能允许相应 DELETE 请求撤销这些动作. 类似地, 实现创作功能的定制用户代理实现, 如使用 HTTP 进行远程操作的修订控制客户端, 可能基于服务器 URI 空间已被设计为对应版本仓库的假设使用 DELETE.

如果 DELETE 方法成功应用, 源服务器应发送

• 如果动作很可能成功但尚未执行, 发送 202 (Accepted) 状态码,
• 如果动作已执行且不再提供进一步信息, 发送 204 (No Content) 状态码, 或
• 如果动作已执行且响应消息包含描述状态的表示, 发送 200 (OK) 状态码.

虽然请求消息定帧独立于所用方法, 但 DELETE 请求中收到的内容没有通用定义语义, 不能改变请求的含义或目标, 并且由于其作为请求走私攻击的潜力, 可能导致某些实现拒绝请求并关闭连接 ([HTTP/1.1] Section 11.2). 除非请求直接发往源服务器, 且该源服务器此前已在带内或带外指示此类请求有目的且将得到充分支持, 否则客户端不应在 DELETE 请求中生成内容. 源服务器不应依赖私有协议来接收内容, 因为 HTTP 通信参与者常不知道请求链上的中介.

DELETE 请求的响应不可缓存. 如果成功 DELETE 请求经过某个缓存, 且该缓存为目标 URI 存有一个或多个响应, 则这些已存储响应将被失效 (见 [CACHING] Section 4.4).

9.3.6. CONNECT

CONNECT 方法请求接收方建立到 request-target 所标识目标源服务器的隧道, 如果成功, 此后将其行为限制为在两个方向上盲转发数据, 直到隧道关闭. 隧道常用于通过一个或多个代理创建端到端虚拟连接, 随后可使用 TLS (Transport Layer Security, [TLS13]) 保护该连接.

CONNECT 仅意图用于发送给代理的请求. 发送 CONNECT 请求的客户端必须发送 authority form 的 request-target (Section 7.1); 即 request-target 仅由隧道目的地的 host 和 port number 组成, 二者以冒号分隔. 例如,

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com

接收方代理可以通过直接连接到 request-target 所标识服务器来建立隧道; 或者, 如果被配置为使用另一代理, 则把 CONNECT 请求转发到下一个入站代理. 任何 2xx (Successful) 响应都表示发送方 (以及所有入站代理) 将在响应头部区段之后立即切换到隧道模式; 该响应之后收到的数据来自 request-target 所标识服务器. 任何非成功响应都表示隧道尚未形成.

当隧道中介检测到任一侧已关闭其连接时, 隧道关闭: 中介必须尝试把来自已关闭一侧的任何未完成数据发送到另一侧, 关闭两个连接, 然后丢弃任何剩余未交付数据.

源服务器可以接受 CONNECT 请求并选择作为隧道一端参与, 大概是出于网络安全或防火墙策略相关的充分理由. 在这种情况下, 源服务器可以终止连接 (如果它直接从客户端收到), 把整个请求消息视为要盲转发的数据, 并把该数据转发到所标识的侦听服务. 或者, 源服务器可以像请求消息意图应用于自身配置一样处理它, 这会绕过对出站流量的防火墙限制 (假设源和目标客户端/服务器对都由同一系统管理员控制). 在任一情况下, 源服务器可以基于请求消息对此类 CONNECT 应用访问控制, 因为如果盲转发, 它可能影响安全或操作.

服务器不得在对 CONNECT 的 2xx (Successful) 响应中发送任何 Transfer-Encoding 或 Content-Length 头字段. 客户端必须忽略在对 CONNECT 的成功响应中收到的任何 Content-Length 或 Transfer-Encoding 头字段.

CONNECT 请求消息没有内容. CONNECT 请求之后发送的数据的解释特定于所用 HTTP 版本. 关于 HTTP/1.1 中 CONNECT 的详情见 [HTTP/1.1] Section 9.3.6.

CONNECT 请求的响应不可缓存.

9.3.7. OPTIONS

OPTIONS 方法请求关于目标资源在源服务器或介入中介处可用通信选项的信息. 该方法允许客户端在不暗示资源动作的情况下确定与资源关联的选项和/或要求, 或服务器能力.

以星号 ("") 作为 request-target (Section 7.1) 的 OPTIONS 请求适用于服务器整体, 而不是某个具体资源. 由于服务器通信选项通常取决于资源, "" 请求只适合作为 "ping" 或 "no-op" 类型的方法; 它除了允许客户端测试服务器能力外不做任何事情. 例如, 这可用于测试代理是否符合 HTTP/1.1 (或不符合).

如果 request-target 不是星号, OPTIONS 请求适用于与目标资源通信时可用的选项.

生成对 OPTIONS 的成功响应的服务器应发送任何可指示服务器实现且适用于目标资源的可选特性的头字段 (例如 Allow), 包括本规范未定义的潜在扩展. 响应内容 (如果有) 也可能以机器可读或人类可读表示描述通信选项. 本规范未定义此类表示的标准格式, 但未来 HTTP 扩展可能定义.

客户端可以在 OPTIONS 请求中发送 Max-Forwards 头字段, 以指向请求链中的特定接收方 (见 Section 7.6.2). 代理在转发请求时不得生成 Max-Forwards 头字段, 除非该请求收到时带有 Max-Forwards 字段.

生成包含内容的 OPTIONS 请求的客户端必须发送有效的 Content-Type 头字段来描述表示媒体类型. 虽然本规范未定义此类内容的任何用途, 但未来 HTTP 扩展可能使用 OPTIONS 内容对目标资源进行更详细查询.

OPTIONS 请求的响应不可缓存.

9.3.8. TRACE

TRACE 方法请求对请求消息进行远程应用层回环. 请求的最终接收方应把收到的消息 (排除下文描述的某些字段) 作为 200 (OK) 响应的内容反射回客户端, 该响应的 Content-Type 为 "message/http" ([HTTP/1.1] Section 8.3.1). 最终接收方要么是源服务器, 要么是请求中收到 Max-Forwards 值为零 (0) 的第一个服务器 (Section 7.6.2).

客户端不得在 TRACE 请求中生成包含敏感数据且可能被响应披露的头字段. 例如, 用户代理在 TRACE 请求中发送已存储用户凭据 [HTTP-AUTH] 或 cookies [COOKIE] 是愚蠢的. 请求最终接收方在生成响应内容时, 应排除任何可能包含敏感数据的请求头字段.

TRACE 允许客户端看到请求链另一端收到的内容, 并把该数据用于测试或诊断信息. Via 头字段 (Section 7.6.3) 的值尤其值得关注, 因为它充当请求链的跟踪. 使用 Max-Forwards 头字段允许客户端限制请求链长度, 这有助于测试在无限循环中转发消息的代理链.

客户端不得在 TRACE 请求中发送内容.

TRACE 请求的响应不可缓存.