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

Re: The Depth header...

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Fri, 7 Sep 2001 10:37:25 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <OFCAC2565B.F8C7C251-ON80256AC0.0033AB9B@portsmouth.uk.ibm.com>

Peter Raymond <Peter.Raymond@merant.com> wrote:

> Hi,
> 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
> 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
> GET methods specifying the label header.
> Why was depth not defined on the GET method? Seems like a really useful
> feature.

In principle there is no problem doing a deep GET, however in practice it
would likey result is a huge response being sent by the server.  That
response would have to be in multi-part MIME format to indicate the types
of the resources that were being returned; and it would not lend itself to
hitting caches maintained by all commonplace proxies.

Given that Depth: does not guarantee an atomic operation (i.e., the results
may be skewed over time) the only advantage is the reduction in GET
requests.  Since GET has no body and can be pipelined for multiple
collection members I don't think it is a huge overhead.

> 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...

I don't have the spec in front of me right now, but that doesn't sound

> on the
> LABEL method if depth is not specified then Depth: 0 is assumed.  It
> 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
> not ask for Depth then apply the operation only to the request resource.
> Why not make the default behaviour of depth consistent?

Rather than be consistent I think we should look at each method and decide
which makes the 'best sense' for that method.

Received on Friday, 7 September 2001 05:40:27 UTC

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