Skip to main content

8. 通用请求和响应处理 (General Request and Response Handling)

8. 通用请求和响应处理 (General Request and Response Handling)​

8.1 错误处理中的优先级 (Precedence in Error Handling)​

服务器必须优先返回授权错误而不是其他错误。这避免了泄漏有关受保护资源的信息(例如,客户端通过对资源的匿名请求看到423 Locked响应来发现隐藏资源的存在)。

8.2 XML的使用 (Use of XML)​

在HTTP/1.1中,方法参数信息专门在HTTP头中编码。与HTTP/1.1不同,WebDAV将方法参数信息编码在XML([REC-XML])请求实体主体或HTTP头中。使用XML编码方法参数的动机是能够向现有结构添加额外的XML元素,提供可扩展性;以及XML能够在ISO 10646字符集中编码信息,提供国际化支持。

除了编码方法参数外,WebDAV还使用XML编码方法的响应,为方法输出和输入提供XML的可扩展性和国际化优势。

当XML用于请求或响应主体时,Content-Type类型应该是application/xml。实现必须接受请求和响应主体中的text/xml和application/xml。不建议使用text/xml。

所有符合DAV的客户端和资源必须使用符合[REC-XML]和[REC-XML-NAMES]的XML解析器。请求或响应中使用的所有XML至少必须是格式良好的并正确使用命名空间。如果服务器收到格式不良的XML,则服务器必须以400(Bad Request)拒绝整个请求。如果客户端在响应中收到格式不良的XML,则客户端不得假设执行的方法的任何结果,并且应该将服务器视为故障。

请注意,处理不受信任来源提交的XML可能会导致与隐私、安全和服务质量相关的风险(见第20节)。服务器可以拒绝可疑的请求(即使它们由格式良好的XML组成),例如,使用400(Bad Request)状态码和解释问题的可选响应主体。

8.3 URL处理 (URL Handling)​

URL出现在请求和响应的许多地方。与[RFC2518]的互操作性经验表明,许多解析Multi-Status响应的客户端没有完全实现[RFC3986]第5节中定义的完整引用解析。因此,特别是服务器需要小心处理响应中的URL,以确保客户端有足够的上下文来解释所有URL。本节中的规则不仅适用于Multi-Status响应中'href'元素中的资源URL,还适用于Destination和If头资源URL。

发送方在两种方法之间进行选择:使用相对引用(针对Request-URI解析),或完整URI。服务器必须确保Multi-Status响应中的每个'href'值使用相同的格式。

WebDAV在其扩展中仅使用一种形式的相对引用,即绝对路径。

Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )

absolute-URI、path-absolute和query生成在[RFC3986]的第4.3、3.3和3.4节中定义。

在Simple-ref生成中,发送方不得:

  • 使用点段("."或"..")，或
  • 具有与Request-URI不匹配的前缀(使用[RFC2616]第3.2.3节中定义的比较规则)。

集合的标识符应该以'/'字符结尾。

####8.3.1 示例 - 正确的URL处理 (Example - Correct URL Handling)

考虑集合http://example.com/sample/,内部成员URL为http://example.com/sample/a%20test,以及下面的PROPFIND请求:

请求 (Request):

PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1

在这种情况下,服务器应该返回两个'href'元素,包含:

  • http://example.com/sample/和http://example.com/sample/a%20test,或
  • /sample/和/sample/a%20test

请注意,即使服务器可能在内部将成员资源存储为'a test',但在URI引用中使用时必须进行百分号编码(见[RFC3986]第2.1节)。还要注意,合法的URI仍可能包含需要在XML字符数据中转义的字符,例如&符号字符。

8.4 请求中的必需主体 (Required Bodies in Requests)​

这些新方法中的一些没有定义主体。服务器必须检查所有请求的主体,即使不期望有主体。在存在请求主体但会被服务器忽略的情况下,服务器必须以415(Unsupported Media Type)拒绝请求。这通知客户端(可能一直在尝试使用扩展)主体无法按照客户端的意图进行处理。

8.5 WebDAV中使用的HTTP头 (HTTP Headers for Use in WebDAV)​

HTTP定义了许多可以在WebDAV请求和响应中使用的头。并非所有这些都适用于所有情况,并且某些交互可能未定义。请注意,HTTP 1.1要求在所有响应中尽可能使用Date头(见[RFC2616]第14.18节)。

服务器必须在检查任何HTTP条件头之前进行授权检查。

8.6 ETag​

HTTP 1.1建议使用ETag而不是修改日期进行缓存控制,并且在创作中更有理由优先使用ETag。ETag的正确使用在分布式创作环境中更为重要,因为ETag与锁一起需要避免丢失更新问题。例如,当锁超时且客户端意外离线或正在进行长时间上传时,客户端可能无法续订锁。当客户端无法续订锁时,只要在此期间没有进行任何更改,资源仍然可以重新锁定,用户可以继续编辑。客户端需要ETag才能区分这种情况。否则,客户端被迫询问用户是否覆盖服务器上的资源,甚至无法告诉用户它是否已更改。时间戳解决这个问题的效果远不如ETag。

强ETag对于创作用例比弱ETag更有用(见[RFC2616]第13.3.3节)。语义等效性可以是一个有用的概念,但这取决于文档类型和应用程序类型,互操作性可能需要本规范和HTTP范围之外的某些协议或标准。还要注意,弱ETag在HTTP中有某些限制,例如,这些不能在If-Match头中使用。

请注意,PUT响应中ETag的含义在本文档或RFC 2616中都没有明确定义(即,ETag是否意味着资源与PUT请求主体逐字节等效,或者服务器是否可能在存储时对文档的格式或内容进行了微小更改)。这是HTTP问题,而不仅仅是WebDAV问题。

因为如果ETag更改,客户端可能被迫提示用户或丢弃已更改的内容,所以WebDAV服务器不应该更改具有未更改主体和位置的资源的ETag(或Last-Modified时间)。ETag表示资源主体或内容的状态。没有类似的方法来判断属性是否已更改。

8.7 包含错误响应主体 (Including Error Response Bodies)​

HTTP和WebDAV直到WebDAV版本控制扩展规范引入了在错误响应主体中包含更具体信息的机制([RFC3253]第1.6节)之前,没有使用大多数错误响应的主体进行机器可解析的信息。错误主体机制适合与可能采用主体但尚未定义主体的任何错误响应一起使用。当状态码可能意味着许多事情时(例如,400 Bad Request可能意味着缺少必需的头,头格式不正确等等),该机制特别合适。此错误主体机制在第16节中介绍。

8.8 命名空间操作对缓存验证器的影响 (Impact of Namespace Operations on Cache Validators)​

请注意,HTTP响应头"Etag"和"Last-Modified"(见[RFC2616]第14.19和14.29节)是按URL(而不是按资源)定义的,并由客户端用于缓存。因此,服务器必须确保执行影响URL命名空间的任何操作(例如COPY、MOVE、DELETE、PUT或MKCOL)确实保留其语义,特别是:

  • 对于任何给定的URL,"Last-Modified"值必须在GET返回的表示每次更改时递增(在时间戳分辨率的限制内)。
  • 对于任何给定的URL,"ETag"值不得用于GET返回的不同表示。

实际上,这意味着服务器

  • 可能必须为命名空间操作的目标命名空间内的每个资源递增"Last-Modified"时间戳,除非它可以更有选择地这样做,并且
  • 类似地,可能必须为这些资源重新分配"ETag"值(除非服务器以使它们在服务器管理的整个URL命名空间中唯一的方式分配实体标签)。

请注意,这些考虑也适用于特定的用例,例如使用PUT在之前已映射但此后已删除的URL处创建新资源。

Last updated on