4.3 Using the Hierarchy

Because the WebDAV data model includes the explicit idea of hierarchy, it's possible to apply some operations to a tree, some to a single node, and some to a node and its direct children. WebDAV achieves this goal by allowing the client to specify the depth to which the operation should be applied. Legal values for depth include only the three values 0, 1, and infinity. Some server implementations are case-sensitive and do not even accept infinity, which is a reasonable way to implement the Depth header, because HTTP header values may be case-sensitive and RFC2518 doesn't say otherwise for this specific header.

Any operation on a resource without children is always depth 0, even if the depth isn't specified. A depth infinity request that addresses a noncollection resource could be rejected with an error, although the WebDAV specification doesn't require this.

Depth is easiest to understand by looking at examples. These examples all take place on requests to the hr/ collection (as shown in Figure 4-3).

Depth 0

Collections may be copied and locked with depth 0, but they may not be moved or deleted with depth 0, because moving or deleting only a collection (and not its children) leaves the namespace inconsistent due to orphaned resources without parents. The properties of a single collection can be queried with depth 0, in which case the server returns only the properties of that collection and none of its children.

In the example shown in Figure 4-4, the collection hr/ is copied with depth 0 to the location hrbackup/, where no resource exists yet. A depth 0 copy operation must copy the collection properties to a new location, without copying any of its children. The collection hrbackup/ will be created empty but with properties copied from hr/. Some server-managed properties (such as DAV:resourcetype and any permissions-related properties) should be copied with existing values to the new location. The server must change certain other server-managed properties (such as DAV:creationdate and DAV:getlastmodified) to appropriate new values to preserve the semantics of those properties.

Figure 4-4. Depth 0 COPY.

graphics/04fig04.jpg

A depth 0 collection copy is only of use to initialize certain property values and permissions. Effectively, the client is using an existing collection as a template for a new collection.

Depth Infinity

Depth infinity is the opposite of depth 0. With depth infinity, the scope of the request includes every resource starting from and including the resource addressed and all of its children recursively, both subcollections and noncollection children. The MOVE, DELETE, COPY, and LOCK operations all support depth infinity requests. Property discovery can also be done with depth infinity.

In the example in Figure 4-5, a depth infinity COPY covers a collection, its properties, its children, and all descendents. The new collection hrbackup/ contains copies of all the descendants of hr/. All new resources must have property values copied from the original resources.

Figure 4-5. Depth infinity COPY.

graphics/04fig05.jpg

Depth infinity copies may partially fail, in which case the server must return detailed information that allows the client to see which parts failed and why.

Depth 1

The depth value 1 is only allowed for PROPFIND requests, so the example illustrating depth 1 must be a property listing. This kind of request is made very frequently. Every time an Explorer-like client interface displays a directory listing, it is displaying the results of a depth 1 property request. If the client requested the resource type property for the hr/ collection (as shown in Figure 4-3) in a depth 1 request, the answer would include:


http://www.example.com/hr/                 collection
http://www.example.com/hr/index.html
http://www.example.com/hr/ergonomics/      collection
http://www.example.com/hr/benefits/        collection

Note that the collection hr/ itself is also included in the depth 1 results because the resource addressed is also included in an operation of any depth. The children of the subfolders are not included as they would be in response to a depth infinity request. The file index.html has a blank resource type because it is not a collection, it is the standard resource type.

The reason depth 1 is forbidden on other requests is that there are namespace consistency and specification issues:

  • A MOVE operation cannot handle depth 1, because it would leave the "grandchildren" of the moved directory orphaned of their parents.

  • A DELETE operation cannot accept depth 1 for the same reason.

  • A COPY operation could theoretically copy just the children of a folder and not the grandchildren, but it's not allowed by the specification. This was probably disallowed in order to simplify, because the designers didn't have a compelling use case for depth 1 copies.

  • A LOCK operation could theoretically lock the directory and its direct children, but again, it's not allowed in WebDAV.



WebDAV. Next Generation Collaborative Web Authoring
WebDAV. Next Generation Collaborative Web Authoring
ISBN: 130652083
EAN: N/A
Year: 2003
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net