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

OPTIONS and Depth (was: Re: Core versioning issues and nits)

From: Greg Stein <gstein@lyra.org>
Date: Sun, 4 Feb 2001 18:31:58 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010204183158.D26044@lyra.org>
On Sun, Feb 04, 2001 at 08:05:06PM -0500, Geoffrey M. Clemm wrote:
>...
> Now this is a good argument for turning the DAV:supported-method-set
> back into a property!  Which is what James Hunt has just asked us
> to do.  I asked him "why".  I think this is a pretty good answer.
> So I'd propose that we switch them back, based on this point that
> Lisa has made.
> 
> Any objections? (I assume that at least James will be in favor :-).
> 
>    This is an order(N) operation, just to show a decent directory listing.
>    Depth is not supported on OPTIONS requests, according to RFC2518: "The
>    Depth header is only supported if a method's definition explicitly
>    provides for such support."
> 
>    This is a serious client issue.  Please address...
> 
> I assume turning the supported-xxx information back into a property
> addresses this concern?

That doesn't make sense. You're always going to have a tension between
OPTIONS for capability discovery and PROPFIND/Depth: for discovery over a
set of resources. supported-xxx was moved to OPTIONS because that is where
discovery normally occurs.

By your logic, we should move the DAV: header into properties.

The right answer is to modify OPTIONS to allow a Depth: header value.

If it comes back with a multistatus, then you know the server understood the
Depth: header. If it didn't respond with a multi, then you probably don't
have a DeltaV server.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sunday, 4 February 2001 21:30:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT