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 09:48:03 UTC