Re: Some problems with the WebDAV protocol

 >    WebDAV can introduce new methods to implement its favorable PUT and DELETE.
> 
> This would make WebDAV useless to downlevel clients (e.g. browsers not
> built specifically to support WebDAV).  Requiring a new header to indicate
> WebDAV semantics has the same effect.

Why? WebDAV servers would still be HTTP/1.1 servers and would implement
HTTP/1.1 semantics for clients that identify themselves as HTTP/1.1 clients.
I actually don't think it would be a good idea to introduce new methods.
There is no problem in changing the semantics of existing ones, as long
as the server has a way of knowing which clients are which and so it can
implement the semantics which is appropriate for the client.
For example: HTTP/1.0 and HTTP/1.1 have different semantics concerning
how persistent connections should be maintained. But since the protocol
is part of both the request and the response nothing gets broken.
An HTTP/1.1 server which gets an HTTP/1.0 request should not maintain
a persistent connection unless the client explicitly asks for it (with
a "Connection: Keep-alive" header). On the other hand, if it gets an
HTTP/1.1 request it should maintain a persistent connection unless the
client explicitly forbids it (with a "Connection: Close" header).

> The HTTP spec makes it clear that it is up to the server to decide
> which requests will succeed.  It only defines what it means for a
> request to succeed.  This means that existing HTTP clients should be
> prepared for requests to fail.  The fact that WebDAV makes certain
> requests fail in a regular fashion for detectable reasons does not
> violate either the letter or intent of the HTTP spec.

Suppose that in two years or so, someone will write a WebDAV2 protocol
that will be extending WebDAV. Suppose further that the current MKCOL
command would not be totally consistent with the philosophy of that new
protocol, and so the new protocol will define a new MKCOL2 method that
behaves slightly differently, and it would require that all MKCOL
requests MUST be forbidden and responded to with a 403.

Since a WebDAV server MAY forbid MKCOL requests (and WebDAV clients
"should be prepared for requests to fail"), there is no problem to make
a server that is both WebDAV compliant and WebDAV2 compliant. The only
problem is that non of the existing WebDAV clients will be able to
create collections on the new kind of server.

Do you think that it would be a good idea to do something like that?

If you have a hosting service with hundreds of clients that rely
on using WebDAV clients to manage their sites. Would you consider
that new requirement to forbid MKCOL as something that is even
remotely acceptable?

One way or the other, this is precisely how the current WebDAV
protocol relates to HTTP/1.1.


Yoram Last

Received on Monday, 19 April 1999 13:30:31 UTC