RE: WebDAV and Open Pluggable Edge Services

Geoff,

of course you're right.

So am I -- however the live property is already there
(DAV:supported-method-set).

;.)

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, March 22, 2002 5:48 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: WebDAV and Open Pluggable Edge Services
>
>
> The "Allow" header that comes back from OPTIONS should
> contain "PUT" iff PUT is allowed on that resource.
> That's probably a reasonable way to detect authorability,
> assuming of course that servers are well-behaved wrt the
> Allow header.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Friday, March 22, 2002 9:47 AM
> 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...)
>
> 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?
>
> //Stefan
>
> Am Freitag den, 22. März 2002, um 14:22, schrieb Clemm, Geoff:
>
> > If you have a URL for the source (i.e. the one that PUT
> > can be applied to), what benefit would EDIT (previously
> > called GETSRC in the recent thread on this subject) have,
> > other than saving you one roundtrip, i.e. instead of a
> > "PROPFIND, GET" you would do an EDIT?
> >
> > In particular, if you are going to use locking for your
> > authoring (which you should :-), you don't want to issue the GET
> > until you have successfully LOCKed the URL (i.e. your sequence
> > will be PROPFIND(source)/LOCK(source-URL)/GET(source-URL).
> > So unless you also want to bundle an implict "LOCK" into the EDIT,
> > you need to do the PROPFIND first anyway.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> >
> > I'm not really a fan of new HTTP methods, but just for interest:
> > Wouldn't a new method like "EDIT" which retrieves the editable
> > content of a resource make our life easier? It could respond
> > with a Content-Location where a PUT can be applied...
> >
>
>

Received on Friday, 22 March 2002 11:54:23 UTC