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

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

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

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

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

cjh

--

Received on Monday, 4 March 2002 17:59:21 UTC