- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 22 Mar 2002 15:56:23 +0100
- To: "Stefan Eissing" <stefan.eissing@greenbytes.de>, <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Friday, March 22, 2002 3:47 PM > To: w3c-dist-auth@w3.org > Subject: Re: WebDAV and Open Pluggable Edge Services > > > Good that I asked. > > Besides locking, one would miss Versioning and Acls using > some kind of EDIT/GETSRC method (not caring about source > URLs). > > So, coming back to HTTP, variants and no-transform, I > conclude that on editable "source" resources servers > should: > - send always "Cache-Control: no-transform" in GET responses > - not vary the response to a GET on any HTTP header > (??? I'm not sure about this one. Julian keeps on > editing variants in his arguments...) I think it can be possible that PUT is possible even if the GET varies. This just means that the PUT will actually overwrite varying entity bodies as well. > That leaves the question: how does a WebDAV client know > that a resource is editable, e.g. that a GET will retrieve > someting that can be PUT back modified again later? > > Users working on a local copy of resources for a week would > be a little disappointed when the server denies the upload > afterwards. And you cannot deduce from successful write LOCKs > that a resource content can be changed. Locking is also used > for property and acl modifications... > > So what is a honest client supposed to do? May be we need a new live property indicating that it's "meaningful" to edit a particular resource? Note that the absence of DAV:source (or it being empty) wouldn't really mean the same thing...
Received on Friday, 22 March 2002 09:56:55 UTC