跳到主要内容

11. HTTP/1.1的状态码扩展 (Status Code Extensions to HTTP/1.1)

11. HTTP/1.1的状态码扩展 (Status Code Extensions to HTTP/1.1)​

以下状态码添加到HTTP/1.1 [RFC2616]中定义的状态码.

11.1 207 Multi-Status​

207(Multi-Status)状态码为多个独立操作提供状态(有关更多信息,请参见第13节).

11.2 422 Unprocessable Entity (无法处理的实体)​

422(Unprocessable Entity)状态码意味着服务器理解请求实体的内容类型(因此415(Unsupported Media Type)状态码不合适),并且请求实体的语法是正确的(因此400(Bad Request)状态码不合适),但无法处理包含的指令.例如,如果XML请求主体包含格式良好(即语法正确)但语义错误的XML指令,则可能出现此错误条件.

11.3 423 Locked (已锁定)​

423(Locked)状态码意味着方法的源或目标资源被锁定.此响应应该包含适当的前置条件或后置条件代码,例如'lock-token-submitted'或'no-conflicting-lock'.

11.4 424 Failed Dependency (依赖失败)​

424(Failed Dependency)状态码意味着无法对资源执行该方法,因为请求的操作依赖于另一个操作,而该操作失败了.例如,如果PROPPATCH方法中的命令失败,那么至少其余的命令也将以424(Failed Dependency)失败.

11.5 507 Insufficient Storage (存储不足)​

507(Insufficient Storage)状态码意味着无法对资源执行该方法,因为服务器无法存储成功完成请求所需的表示.此条件被认为是临时的.如果收到此状态码的请求是用户操作的结果,则在由单独的用户操作请求之前,不得重复该请求.

12. HTTP 状态码的使用 (Use of HTTP Status Codes)​

这些 HTTP 状态码并未被重新定义, 但 WebDAV 方法和要求在一定程度上扩展了其使用方式. 通常, 许多 HTTP 状态码都可以用于响应任意请求, 不限于本文档所述情形. 还应注意, 已知 WebDAV 服务器会使用 300 级重定向响应 (早期互操作性测试发现客户端并未准备好处理这些响应). 当服务器响应请求创建了新资源时, 不得使用 300 级响应.

12.1 412 Precondition Failed​

任何请求都可以包含 HTTP 中定义的条件 Header (If-Match, If-Modified-Since 等), 或本规范定义的 "If" 或 "Overwrite" 条件 Header. 如果服务器求值某个条件 Header, 且该条件不成立, 则必须返回此错误码. 另一方面, 如果客户端未在请求中包含条件 Header, 则服务器不得使用此状态码.

12.2 414 Request-URI Too Long​

在 HTTP 1.1 中, 此状态码仅用于 Request-URI, 不用于其他位置的 URI.

13. 多状态响应 (Multi-Status Response)​

Multi-Status 响应在可能适用多个状态码的情形下传达多个资源的信息. 默认的 Multi-Status 响应主体是一个 text/xml 或 application/xml HTTP 实体, 其根元素为 'multistatus'. 其他元素包含方法调用期间生成的 200, 300, 400 和 500 系列状态码. 100 系列状态码不应该记录在 'response' XML 元素中.

虽然 '207' 用作整体响应状态码, 但接收方需要查看 multistatus 响应主体的内容, 以获得方法执行成功或失败的进一步信息. 该响应可以用于成功, 部分成功以及失败情形.

'multistatus' 根元素按任意顺序包含零个或多个 'response' 元素, 每个元素都包含某个单独资源的信息. 每个 'response' 元素必须具有一个用于标识资源的 'href' 元素.

Multi-Status 响应使用以下两种不同格式之一来表示状态:

  1. 作为 'response' 元素子元素的 'status' 元素表示针对所标识资源整体执行消息的状态 (例如, 见第 9.6.2 节). 某些方法定义会说明客户端应准备在响应中看到的特定状态码. 不过, 客户端必须能够使用 [RFC2616] 第 10 节定义的通用规则处理其他状态码.

  2. 对 PROPFIND 和 PROPPATCH, 该格式已通过使用 'propstat' 元素而非 'status' 元素进行扩展, 以提供资源各个属性的信息. 此格式专用于 PROPFIND 和 PROPPATCH, 并在第 9.1 节和第 9.2 节中详细说明.

13.1 响应 Header (Response Headers)​

HTTP 定义 Location Header, 用于指示 Request-URI 所寻址资源的首选 URL (例如在成功 PUT 请求的响应中或重定向响应中). 然而, 当响应主体中存在 URL 时, 例如 Multi-Status, 使用此 Header 会产生歧义. 因此, Location Header 与 Multi-Status 响应结合使用的语义有意保持未定义.

13.2 处理被重定向的子资源 (Handling Redirected Child Resources)​

HTTP 1.1 中定义的重定向响应 (300-303, 305 和 307) 通常带有 Location Header, 用于指示从 Request-URI 重定向出去的单个资源的新 URI. Multi-Status 响应包含许多资源地址, 但 [RFC2518] 中的原始定义没有为服务器提供被重定向资源的新 URI 留出位置. 本规范确实为此信息定义了 'location' 元素 (见第 14.9 节). 服务器必须在 Multi-Status 中的重定向响应里使用这个新元素.

客户端在 Multi-Status 中遇到被重定向的资源时, 不得依赖 'location' 元素一定存在并带有新 URI. 如果该元素不存在, 客户端可以向单个被重定向资源重新发出请求, 因为该请求的响应可以通过包含新 URI 的 Location Header 进行重定向.

13.3 内部状态码 (Internal Status Codes)​

第 9.2.1, 9.1.2, 9.6.1, 9.8.3 和 9.9.2 节定义了 Multi-Status 响应中使用的各种状态码. 本规范不定义可能出现在这些响应中的其他状态码的含义.

最后于 更新