W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

The Depth header...

From: Peter Raymond <Peter.Raymond@merant.com>
Date: Fri, 7 Sep 2001 10:00:06 +0100
Message-ID: <20CF1CE11441D411919C0008C7C5A13B027AA36E@stalmail.eu.merant.com>
To: ietf-dav-versioning@w3.org

I have a few issues/questions surrounding the use of the depth header...

As Geoff pointed out in his reply to my message on the Vary header, GET 
does not take a Depth header.  This would have been really useful, this 
came up in one of our deltav study groups here in MERANT...the scenario 
was this:

You are a Working-Resource based client and are using labels to identify 
files to be used in a build (this is a common use of labels, the label 
selects which versions are to be included in a build).

If we could do a GET with a Depth header and supply the label in the label
header then in one operation we could retrieve all files needed for the
Since the spec does not allow Depth on GET we would have to do a PROPFIND
to get the DAV:label-name-set (or do a DASL query) and then issue multiple
GET methods specifying the label header.
Why was depth not defined on the GET method? Seems like a really useful

The second issue I have with the depth header is they way it is defined 
inconsistently on each method that uses it....for example on the UPDATE 
method if depth is not specified then Depth: infinity is assumed...on the 
LABEL method if depth is not specified then Depth: 0 is assumed.  It would 
make server implementation cleaner if we could always assume Depth: 0 in 
the absence of a Depth header.  This also seems logical, if the client does 
not ask for Depth then apply the operation only to the request resource.
Why not make the default behaviour of depth consistent?

Peter Raymond - MERANT
Technical Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
WWW: http://www.merant.com
Received on Friday, 7 September 2001 05:01:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC