RFC4918
搜索 K

Appearance

5. 网络资源集合 ​

本节提供了一种 Web 资源类型 (集合) 的描述，并讨论了它与 HTTP URL 命名空间以及 HTTP methods 是如何互动的。集合资源 (Collection Resource) 这种类型资源存在的目的是给服务器端支持命名空间的类集合对象 (例如文件系统的目录) 进行建模。

所有符合 DAV 协议的资源都必须支持这个 HTTP URL 命名空间模型。

5.1 HTTP URL 名称空间模型 ​

HTTP URL 命名空间是一个层次结构的命名空间，层次结构以“/”字符分隔。

如果一个 HTTP URL 命名空间满足以下条件，它就被称为一致的：对于每一个 HTTP 层级结构的 URL，都存在一个包含它作为内部成员 URL 的集合。根集合或者顶层集合不需要遵守此条规则。

顶层集合的命名空间不一定必须由绝对路径'/'进行标识——它可以由一个或多个路径分段来标识 (例如，/servlets/webdav/…)

HTTP/1.1 和 WebDAV 都不要求整个 HTTP URL 名称空间是一致的——一个 WebDAV 兼容的资源可能没有父集合。尽管如此，某些 WebDAV methods 被禁止产生导致名称空间不一致的结果。

正如在[RFC2616]和[RFC3986]中所隐含的，任何资源，包括集合资源，都可以被超过一个 URI 进行标识。例如，一个资源就可以由多个 HTTP URL 来标识。

5.2 集合资源 (Collection Resources) ​

集合资源不同于其他资源，因为它们也充当容器。一些 HTTP methods 仅应用于集合，另一些 methods 仅适用于部分或全部被集合所定义而存在一个容器之内的资源。当 method 的应用范围不清楚时，客户端可以指定一个层级深度 (Depth)。深度可以是 0 级 (只有集合)，1 级 (集合和它直接包含的资源)，或者无限级 (集合和所有该集合递归包含的后代资源)。

集合的状态至少包含一组路径分段到资源的映射，以及集合本身的一组属性。在本文档中，如果存在一个路径被映射指向资源 B，而这个路径又被包含在 A 资源的路径里，我们就可以说资源 B 被资源 A 包含。一个集合最多只能被一个路径映射所指向，而一个路径被映射指向多个资源是不合法的。

集合上定义的属性与非集合资源上的属性行为完全相同。集合可能有额外的状态，比如 GET 返回的实体内容。

有 A 和 B 两个兼容 WebDAV 标准的资源，分别被通过 URL 标识为“U”和“V”，“V”等于“U/SEGMENT”，那么 A 就必须是一个集合，这个集合必须包含一个从“SEGMENT”指向到 B 的映射。所以，如果 WebDAV 兼容的 B 资源 URL 是“http://example.com/bar/blah”，同样 WebDAV 兼容的 A 资源 URL 是“http://example.com/bar/”，那么 A 资源就必须是一个集合，而且这个集合必须含有一个从 "blah" 指向 B 的唯一映射（集合 A 可以包含多个成员映射，但是从 blah 指向 B 的只能有一个）。

虽然一般而言一个映射由单个路径分段和一个资源组成，但有时候，一个映射也可以由由一组路径分段和一个资源组成。这允许服务器将一组路径分段视为等价的 (要么这一组的所有路径分段都映射到相同的资源，要么没有一个段映射到一个资源)。例如，一个对路径大小写不敏感的服务器，会将以下分段“ab”，“Ab”，“aB”和“AB”等同对待。然后客户端可以使用这些段中的任何一个来标识资源。请注意，PROPFIND 的结果将选择这些等效段中的一个来标识映射，因此是一个映射对应一个 PROPFIND 响应元素，而不是映射中的每个路径分段都有一个。

集合资源在 HTTP URL 命名空间层次结构中可以有指向非 WebdDAV 兼容资源的映射，但这不是必需的。例如，如果 URL 为“http://example.com/bar/blah”的资源 X 不兼容 WebDAV，而 URL 为“http://example.com/bar/”的资源 A 标识一个 WebDAV 集合，那么 A 可能有从“blah”到 X 的映射，也可能没有。

如果兼容 WebDAV 的资源在 HTTP URL 命名空间层次结构中没有符合 WebDAV 标准的内部成员，那么这个兼容 WebDAV 的资源就不需要是一个集合。

有一个固定的约定，即当一个集合资源不带尾斜杠时，服务器可能会自动当成有尾斜杠来处理请求，这时候，它会在响应中返回一个 Content Location header，指向以“/”结尾的 URL。例如，如果客户端调用 http://example.com/blah 上的方法 (没有尾随斜杠)，服务器可能会像在 http://example.com/blah/ (尾随斜杠) 上调用操作一样响应，并且应该返回一个具有 http://example.com/blah/ 值的 Content-Location 头。无论何时服务器要生成一个指向集合的 URL 都必须包含末尾的斜杠。通常，客户端也应该使用带末尾斜杠的集合名形式。如果客户端没有使用末尾的斜杠，那么客户端需要做好看到一个重定向响应的准备。客户端会发现，如果你想知道请求的资源是否是个集合，那么通过 DAV:resourcetype 属性比通过 URL 进行判断更可靠。

客户端必须能够支持 WebDAV 资源被非 WebDAV 资源包含的情况。换言之，如果来自“http://example.com/servlet/dav/collection”的选项响应表明支持 WebDAV，客户端不能自行假定“http://example.com/servlet/dav/”或它的父类一定是个 WebDAV 集合。

一个典型的“映射的 url 不作为其父集合的成员出现”的场景就是“服务器允许连接或者重定向到一个非 WebDAV 资源”的情形。例如“/col/link”，尽管服务器会对它的 GET 请求返回一个 302 状态响应，但它并不会作为“/col/”的成员出现，尽管如此，URL“/col/link”也确实被映射了。类似地，一个动态生成的页面可能有一个来自“/col/index.html”的静态 URL 映射。因此，该资源尽管不是“/col/”的成员，但是依然可以 200 OK 响应 GET 请求。

一些指向 WebDAV 兼容资源的映射也可能不会出现在父集合中。符合这种情况的例子是那些为每个 WebDAV 兼容资源提供多别称 URL 支持功能的服务器。一个服务器可能会实现大小写不敏感的 url，这样的话“/col/a”和“/col/A”会标识同一个资源，但在被要求列出“/col”的成员时，只会出现一个“a”或“A”。在服务器将一组路径分段名视为等价的情况下，服务器必须在 PROPFIND 响应中对每个映射只公开一个首选段。