W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: DAV-Enabled field (was RE: A case for GETSRC)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 2 Mar 2002 02:07:41 +0100
To: "CJ Holmes" <cholmes@4d.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAECOECAA.julian.reschke@gmx.de>
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Saturday, March 02, 2002 2:01 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)
> >  > Call it DAV-Enabled.  The value must be present but is ignored.  (If
> >>  someone got ambitious it could be used by the client to indicate its
> >  > capabilities.  But one problem at a time, OK?)
> >>
> >It doesn't change the issue that you'd be using the same URI for
> different
> >resources. That's a very basic problem, and no amount of syntactic sugar
> >makes it go away.
> Yeah, but it's OUR problem, and not yours.  If our DAV implementation
> is unsatisfactory to our customers then we have to change it.  But
> this would let us (and other implementors) give our customers what
> they want, which is DAV access to their source files with virtually
> no configuration necessary.
> All we need from the protocol group is a sure way to know that a GET
> command originated from a DAV client.  Is that so much to ask?

To be honest: yes.

GET is GET. It doesn't matter what client it comes from. You shouldn't try
to change that.
Received on Friday, 1 March 2002 20:08:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:25 UTC