Re: Some problems with the WebDAV protocol

>What you did with PUT/DELETE is really very similar to all of the
>above. It is not within the legitimate scope of a protocol to
>take away functionality of other protocols, or to otherwise
>change the semantics of the other protocol's methods.
>You could legitimately do any of:
>a) Use new methods.
>Or
>b) Use a header to distinguish WebDAV from HTTP/1.1.
>Or
>c) Accept and use HTTP/1.1 methods as they are defined in HTTP/1.1.

Just for the record, I agree with this argument. It is the responsibility
of a new protocol to allow for interoperability with existing protocols
when it is possible to do so.  That is the price WebDAV agreed to pay
when it chose HTTP/1.1 as its base, just as HTTP/1.1 contains many design
decisions that were due to compatibility with HTTP/1.0.

In this case, I expect the WebDAV specification to be changed when it
moves from Proposed to Draft status.  The requirement would change from
a MUST to a "SHOULD ..., unless the User-Agent request-header field 
indicates a client that is known not to support the MKCOL method."

As for the 207 response code, it cannot be used in response to any
request that completely failed.  Whether that requires a change to DAV
or not is up to the working group, but the HTTP semantics are clear.
Failure of the reviewers to detect this obvious protocol error is not
a valid excuse for its continuation.  The last time I brought up the
same question, I was assured that the 207 response is only used when
at least part of the request succeeded.  In any case, I still think the
whole idea of multi-status is bogus, so it is difficult for me to review
it beyond that point.  When a protocol becomes unnecessarily complicated,
mistakes are bound to happen.

....Roy

Received on Wednesday, 21 April 1999 21:28:02 UTC