RE: The Depth header...

Peter Raymond <Peter.Raymond@merant.com>

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

I meant that if the deep GET included requests for numerous resources'
content that were already in the proxy cache, the chances are that the
proxy will not be able to satisy the request because it could not construct
a multistatus response (or whatever is used to marshal the response).
Similarly, when a large multistatus is returned the proxy will not know how
to split it up and cache individual resource content for future GET
requests.

(p.s. In retrospect, my comment on multi-part MIME may be wrong, but I
meant that the response would have to include info that is normally
returned in the GET response header, such as MIME-type & encoding).

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

The deep operations only make sense when the request body includes a
DAV:label-name element.

I agree that the default should be depth zero.

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

We can debate whether the method has 'dispatch precedence' over the Depth:
header (i.e., causes a branch in the code logic) but I don't think that is
a useful discussion.

I think we should aim for the default value to do the 'Natural Thing' for
each method, and where it is a matter of debate be consistent.  I agree it
is not a big deal, but just ask server implementers who have to support
PROPFIND depth infinity as the default value and see how they like that<g>

Regards,
Tim

Received on Friday, 7 September 2001 07:38:14 UTC