Re: Some problems with the WebDAV protocol

> > So an HTTP/1.1
> > client must interpret a 207 as being the same as a 200, although it clearly
> > has a totally different meaning in WebDAV.
> 
> I say again: it is not clear that the meaning is totally different.

If it isn't different, then it would be OK to return a 200 response code
to a WebDAV client in any event that only part of the collection had
been deleted. Is that right?

> > > That's a matter of opinion; I say it should be possible to delete a collection and
> > > know that clients that don't MKCOL it won't recreate it.  The fact is that, as you
> > > admit, the HTTP/1.1 spec does not forbid the behavior which DAV prescribes.
> >
> > Nor does HTTP/1.1 forbids to disallow PUT altogether, or to disallow
> > resource names to have more than 5 characters, or...  The point is that
> > it does allow functionality that WebDAV forbids, and this functionality
> > is being used (so it's not a purely theoretical matter).
> 
> But it's pretty close to theoretical, because the client-side changes to switch from "do
> a PUT and know that it'll create a collection" to "do a MKCOL followed by a PUT" are
> trivial.

And how do I do a MKCOL if I use Amaya, Netscape composer, AOLpress, etc.,...?
 
> > Using DAV-like functionality of base HTTP/1.1 is one thing. Redefining that
> > functionality is another.
> 
> I assert again that we are not redefining anything; that the changes you see are totally
> consistent with the HTTP/1.1 spec.

If you make changes you are redefining (by definition).
 
> > > > Another (not related) problem with the current protocol is the requirement
> > > > that servers must respect PROPFIND with Depth=infinity queries for collections.
> > >
> > > Access control.
> >
> > And this helps how? By making public content repositories outside the scope
> > of WebDAV?
> 
> No, by requiring special access rights for Depth=infinity.

And when the request fails, how do you convey that to client?
What status code will you use? How will the client know why the request failed
and how it should proceed? Besides, if I can restrict access by the Depth
of a request, then I can do so for the entire server. How does that go along
with:
"DAV compliant servers MUST support the "0", "1" and "infinity" behaviors."
and
"the multistatus XML element for a collection resource with member URIs MUST
include a response XML element for each member URI of the collection, to
whatever depth was requested." ???


Yoram Last

Received on Monday, 19 April 1999 13:29:19 UTC