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

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Monday, March 04, 2002 11:58 PM
> To: DAV
> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)
>
>
> >  > All I'm asking for at this point is some way for server implementors
> >>  to know when a GET arrives from a DAV client.  A DAV-Enabled (or
> >>  whatever) field on the requests would do that.  I'm not trying to
> >>  break the model, or add new methods.  I just want to know when a DAV
> >>  client is GETting a resource vs a normal web client.
> >
> >This *is* the problem. GET is GET. It's an HTTP method. Once you
> are making
> >it depend on the type of client, you *are* breaking the HTTP model.
>
> GET returns different things for all kinds of different reasons.  The
> time of day, the browser in use, the phase of the moon,
> authentication credentials, your IP address, how much coffee is left
> in the coffee machine, etc..

Yes, but all of these *by definition* still are representations of the same
resource. You can't argue with this, this is how it is defined.

> The body that is returned from GET is a policy matter that is
> determined by the administrator, not by this list.

Yes, but if you allow the same URL both to respond with it's source and
generated output, it will be hard to define what this resource *is* (give a
definition!). You can't say anymore: "it's a representation of the current
user's shopping cart".

> >  > Why?  Because what most users expect is to be able to edit their
> >>  pages at the same URI.  I realize that doesn't fit your model, but it
> >>  is what most people really want from DAV.
> >
> >People want to send around URL that point to output resources.
> They *also*
> >want to send around URLs that point to source resources. This
> isn't possible
> >if the URLs are the same.
>
> Again, not your problem.  If someone *wants* to have a special URI
> space for DAV access, then they are welcome to configure their
> server's policy accordingly.

If they do, they can use DAV:source. Great. Problem solved. No need for a
new protocol which (in my opinion) breaks HTTP.

> >  > Even assuming we were to implement a way for our DAV to map sources
> >  > onto some user-configurable alternate URI space with a minimal amount
> >  > of configuration, one of the first things people would ask us is why
> >  > they can't use the same URIs for DAV and for their web browser.  And
> >  > they aren't going to understand the data modeling argument.
> >
> >But maybe they would be able to understand my previous argument?
>
> Eventually.  But they would rather the thing "just work".  Latter on
> they'll read the manual, figure out other configurations, and decide
> if they want to change how they're doing things.

So you're proposing to change the basic definition of GET because you feel
it's harder to explain the proper solution to your users? That's really a
weak argument.

> >I disagree. Your proposal breaks GET in a very fundamental way.
>
> Nah...  It is still GET.  I'm just asking for the input I need for
> policy decisions.  The bandwidth is minimal, the processing time
> required is about nil, what's not to like?

GET is GET. It shouldn't depend on whether a client happens to know that
WebDAV exists. Just because a user agent knows about PROPFIND doesn't mean
that it never will want to GET the output resource. And a user agent that
happens *not* to know about WebDAV still should be able to get the source.

WebDAV doesn't replace HTTP, it *extends* HTTP. HTTP defines how GET is
working, not WebDAV.

Received on Monday, 4 March 2002 18:24:47 UTC