RE: The Depth header...

Hi,

[Tim wrote:]

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

Yes, I agree it would be large and would have to be multi-part MIME, I don't

know a lot about caching HTTP proxies, but would have thought they could 
handle this.

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

OK, I think this makes sense, I hadn't read much about HTTP pipelining
but looking at RFC2616 it seems this would solve my performance concern
about multiple roundtrips etc.

>> 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
>good?!

Yes, section 7.1 seems to be saying that the default is to UPDATE
the whole configuration...it says:

"The request-URL identifies the set of possible update targets.  If 
Depth:0 is specified, the request-URL is the only possible update 
target; otherwise, any member of the configuration rooted at the 
request-URL is a possible update target."

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

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

I disagree, this leads to implementations where you need different code
for each method (or a nasty set of if-statements) just to work out what
a default should be...eg...

if (depth header not specified)
{
  if (method==UPDATE)
	depth=infinity;
  else if (method==LABEL)
	depth=0;
  else if....
}

Also clients have to be aware what the default will be given the different
methods it is sending (or always be paranoid and specify depth).
Also helps keep the spec tidy so instead of specifying on each method what
the default depth is we can specify it in just one place at the top of the
spec.

I guess it's not a big issue for me, I just prefer a consistent definition
of behaviour where possible.

Regards,
--
Peter Raymond - MERANT
Technical Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com