Re: Some problems with the WebDAV protocol (part 1: philosophy)

> > If you are issuing this request, you should have had some prior
> > knowledge concerning the nature of that resource (like the fact that it
> > is a CGI program capable of processing certain parameters).
> 
> This is absolutely false.  A user-agent is not required to know anything
> about the nature of the resource to which it is submitting a GET request.

Required no. But, it wouldn't be very productive to shoot GET requests at
random. Requests of the type I discussed would typically be the result of
form submission, and the form from which they where generated represents
prior knowledge concerning the nature of that specific resource.

> > Moreover, even those things that you
> > did know about the URI, are completely outside the scope of the HTTP
> > protocol.
> 
> This is because, except for a few characters defined in RFC 2396 ("Uniform
> Resource Identifiers (URI): Generic Syntax"), a URI is an opaque string.

Precisely. This is how HTTP sees it. However, both servers and clients recognize
things in URIs that are outside the scope of HTTP itself.

> > Not how requests should be handled or what kind of responses should be
> > provided. This nature of HTTP is what makes it such a flexible protocol.
> 
> Interpreted literally, these sentences would appear to be easily
> contradicted by the definitions of methods in section 9 of RFC 2068.

This statement is intended to be qualified by the "mostly" that was originally
a few lines above it. Since I consider GET and POST to be the "heart" of HTTP,
and most of its other methods as being essentially "helper methods", I think
that this statement describes quite well what HTTP is "mostly" not doing.

> Unlike the definition of GET, which is sufficiently open to allow dynamic
> content to be returned, yielding a net positive effect on the Web, the loose
> definitions of PUT and DELETE trade off interoperability for no net positive
> effect.  

Most of what you call "loose definitions" are inevitable in the context of HTTP.
A protocol can't specify behavior for objects that do not exist within its scope.
This by itself does not at all mean that any looseness should exist in actual
applications, because the behavior can be specified by common practices or
other standards.

> It's all loss -- having loose definitions of these methods doesn't
> gain you new, compelling use environments, or new compelling services, they
> just result in interoperability problems.

Since HTTP has built-in limits on what it can specify, there is no
constructiveness in taking this view. It is a fact of life that most HTTP
applications are based on many things that fall outside the scope of the
HTTP protocol itself. For example, the fact that most HTTP servers send
HTML entity bodies along with most error status codes is a common practice
(which is based on the assumption that HTML is an appropriate media type
for HTTP applications) that has nothing to do with HTTP itself. To the
extent that there are really any differences in how PUT/DELETE get
implemented (the actual differences are very mild, and they translate
into some servers allowing what others do not), this by itself proves that
some implementors found certain implementations to be better suited for
their applications. Flexibility may be problematic in the context of some
applications, but it is never an "all loss."

> Do you need to know how your FTP server is implemented in order to use it?

Actually, yes. Standard UNIX FTP applications (clients and servers) provide
a considerable amount of useful functionality (for example, all those
commands that control UMASKs and file permissions) through the SITE command.
This functionality only exists in conjunction with FTP servers that are
implemented over appropriate types of file systems, and moreover, its
interoperable implementation depends on common practices that fall outside
the scope of the FTP protocol itself.

> What you are reporting are the symptoms of a
> poorly specified method, not some glowing example which should be held up
> for all to gaze at and admire.

No. I think that this whole debate is the result of misinterpreting a
certain protocol as supposed to be what it isn't. It's like saying that a
hammer is a broken screwdriver, because it isn't optimized for driving screws
into the wall. A hammer is simply a hammer, though.

> The current definition of DELETE is bad, and has no advantages.  In my
> personal opinion, it should have been left out of the HTTP spec., along with
> PUT.

I can see your point here. However, I think that what you should really be
saying is that the HTTP protocol does not specify these methods well enough for 
the purpose of what WebDAV is trying accomplish. I agree that from the narrow
perspective of WebDAV, things would have been simpler if HTTP did not have
these methods at all. In my own view, having these methods (as they are) in
HTTP is a good thing, but this debate in itself is quite irrelevant here.
HTTP already has these methods (along with other methods that where never
optimized for the purpose of what WebDAV is trying to do), and WebDAV needs
to accept the pre-existence of these HTTP methods as given constraints on its
design.

> > WebDAV, on the other hand, is a totally different protocol with totally
> > different goals and totally different design philosophy.
> 
> WebDAV is an extension of HTTP, thus it is not a *totally* different
> protocol from HTTP. Since HTTP has PUT and DELETE, presumably remote
> authoring was a goal of HTTP, and hence WebDAV does not have *totally*
> different goals from HTTP.  And from my perspective, I don't feel that I
> helped develop a protocol which had a totally different design philosophy
> from HTTP.  So I don't agree with your assertion :-)

The word "totally" doesn't carry a whole lot of significant information here,
so there isn't much point in arguing about it. Also, the "goal of HTTP" isn't
so important here. Its actual usage and potential usage are. In any event,
I think that WebDAV's design suffers from the apparent tendency of its
designers to view it as an integral part of "what HTTP should have been"
(in their opinion) rather than viewing it as a different protocol. The
PUT/DELETE collision is just a symptom of that. Another symptom (in my
opinion) is the absence of an appropriate retrieval method in WebDAV. HTTP
GET isn't really tuned for what one wants to have in WebDAV. I think that
WebDAV would have gained from having a different retrieval method that
would:
1) Behave the same as HTTP GET for static resources (namely for files).
2) Would retrieve the editable "source" for dynamic resources.
3) Would return a 404 in case that a resource does not really have any
 editable resource associated with it (like in the case of a directory for
 which GET returns an automatically generated directory listing).
4) Can be used to place a LOCK on a resource with the same operation
 that retrieves it for editing.

Whether one uses a different method name (like EDIT) or a header to change
the semantics of GET isn't so important. The current WebDAV workaround
(using a different URI to denote the "source" of a dynamic resource) is
neither natural nor easy to implement. You can take a look at Netscape's
Enterprise server to see how nicely it works out to have a separate EDIT
method.

> > It deals with
> > defining a great deal of server-side structure, and specifying a great
> > deal about how requests should be handled and responded to, and
> > it leaves very few things open to interpretation or handling by other
> > protocols.
> 
> As stated before, I view the concreteness of the language in the WebDAV
> spec. to generally be a plus.  A client can execute a DAV method against a
> DAV server and by examining the response, have a reasonably clear
> understanding of what just happened on the server.  This is a good thing.

It is a good thing as long as this concreteness truly matches what people
are trying to do with this protocol. It's all a question of getting the
right balance, and getting the right balance might be very hard to do in
advance. I think that being perceptive to how WebDAV ends up being used
and implemented in the real world would be a good thing. Note that a
significant part of writing HTTP was documenting common practices that
already existed when it got written. WebDAV is quite different in this
respect.

> > It is certainly not a communication protocol.
> 
> I really don't understand what you mean when you say "communication
> protocol"

It was meant in the same loose sense that I would call a telephone
a "communication device." That is, a protocol that defines a communication
layer over which information is conveyed from one side to the other (like
TCP). I qualified HTTP as being *mostly* (albeit clearly not *purely*) such
a protocol. It would clearly not be true to say the same thing about WebDAV.

> > This is nice
> > and legitimate (except for those aspects of it that are flawed), but
> > you can't interpret HTTP as being the same thing as WebDAV. WebDAV
> > could have been designed as being purely layered on top of HTTP as it
> > is. The fact that you *choose* to design it through HTTP extensions does
> > not make these two different protocols the same. (which is all the more
> > reason why it was a bad design error to put them in conflict.)
> 
> I'm afraid I don't understand this paragraph.

Like you said yourself, one can tunnel a whole protocol over POST. WebDAV
*could* have been designed in this way. (This wouldn't be all that
different from the way Microsoft's FrontPage currently works.)


Yoram

Received on Sunday, 2 May 1999 18:43:49 UTC