- From: Elias Sinderson <elias@cse.ucsc.edu>
- Date: Wed, 15 Oct 2003 15:40:48 -0700
- To: w3c-dist-auth@w3.org
- Message-ID: <3F8DCCF0.7090305@cse.ucsc.edu>
I agree, let's add this to 2518bis - the proposed mechnism is simple and easy for developers to understand. Elias Geoffrey M Clemm wrote: > > I support this addition to RFC2518bis. > > I believe it is a key mechanism needed for servers to properly support > the various current (and future) WebDAV extensions. > > Cheers, > Geoff > > Julian wrote on 10/14/2003 09:53:30 AM: > > > > > > OK, > > > > > > so we probably should put it onto the issues list (so that it > doesn't get > > lost). > > > > Here's a proposal for the issues list: > > > > > > Issue DAV_REQUEST_HEADER > > > > RFC 2518 provides a mechanism (the "DAV" response header) for a > server to > > indicate to a client that it supports a specific WebDAV option (e.g. > "1", > > "2", "version-control", etc.), but there is no complementary > mechanism for a > > client to indicate to a server that it understands a specific WebDAV > option. > > This becomes an issue when a WebDAV extension (or revision) needs to > change > > response formats in a way that possibly break existing clients. > Detecting > > client features based on a single, well-defined request header will work > > better than (for instance) relying on custom headers (specified by each > > extension) or "User-Agent". > > > > Suggested resolution: allow the use of the "DAV" header as a request > header, > > with the same set of values that are defined for the "DAV" > > response header. > > > > > > Regards, Julian > > > > -- > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > >
Received on Wednesday, 15 October 2003 18:40:59 UTC