Re: Some problems with the WebDAV protocol

 
> The rationale for the extra constraints on PUT in WebDAV is:
> 
> * Prevention of creation of intermediate collections on user error.
> 
> Say I'm authoring a resource with URL:
> 
> http://authoring.mycorp.com/users/jim/1999_reports/q1_report/rpt.htm
> 
> And suppose that the server supports PUT, and does actually create
> intermediate collections as needed (as allowed by HTTP/1.1):
> 
> Now, what happens if, when I go to save a backup of this report, I type in
> the URL:
> 
> http://authoring.mycorp.com/users/jim/1999-reports/q1_report/rpt.htm
> 
> (That is, the "_" in "1999_reports" is now a "-") Now, instead of getting an
> error, my server has gone ahead and made two new collections for me
> (1999-reports, and "q1_report"), a behavior I did not want.

This seems like a fairly mild problem. Besides, the potential for
having this problem is purely the result of a user interface that lets
you create a whole path with one command. It has nothing to do with
the protocol. You can (and surely will) have applications that would do
that anyway, namely, you will type the desired URI, and then the client
program would automatically create the missing collections with MKCOL.
What does it matter if this is done by the client or the server? 

> * Not *requiring* the creation of intermediate collections to support
> namespace consistency
> 
> As far as HTTP/1.1 is concerned, a server is free to have what I term "free
> floating URLs", URLs that, if you remove the last path segment, do not
> resolve to a resource.
> 
> For example:
> 
> http://example.com/foo/fuzz/bar.html
> 
> This URL would be free floating if you removed the "bar.html" path segment
> to create:
> 
> http://example.com/foo/fuzz/
> 
> AND if this URL is not mapped to a resource.
> 
> In WebDAV, we wanted to prevent free-floating resources, since they would
> violate namespace consistency (that, ideally, every URL for a DAV-compliant
> resource must belong to a collection).

I fail to see what is the problem. If a server has a problem to create certain
URI's, because that would conflict with namespace consistency, then it shouldn't
allow *those* URIs to be created. Clearly in many cases, the server can create
the "missing" collections without any namespace consistency problems.

> This would have required us to add a
> requirement that a PUT to a URL would have to create all intermediate
> collections.  But, this seemed to us to be adding excessive side-effects to
> PUT, especially since a user might not even want those extra collections to
> be created (i.e., they might have just committed an error).

Why do you think that you must *require* things to be one way or the other?

> So, while you may not agree with this rationale, the requirement was not
> added arbitrarily.

I actually agree that if you have MKCOL, then it makes more sense to use it,
but your arguments for why PUT-based creation of collections must be
completely banned are very weak. It is pretty close to arbitrary.

> OK, so given that WebDAV has this extra requirement on PUT that HTTP/1.1
> does not have, you are assering that a downlevel HTTP/1.1 authoring client
> would experience interoperability problems authoring against a DAV server
> (or a DAV-capable portion of a server's namespace).  It seems to me that, if
> users of these downlevel clients depend on the side-effect behavior of PUT
> to create intermediate collections, they might indeed have some difficulty
> authoring against a DAV-capable server.
> 
> So, having agreed to your main point, we are now left to argue over the
> severity of this interoperability problem.  I assert that it is minor, since
> there are several existing workarounds.
> 
> Workaround #1:
> Use an existing DAV client as a helper to create the intermediate
> collections.
> 
> This addresses your question:
> > And how do I do a MKCOL if I use Amaya, Netscape composer, AOLpress,
> etc.,...?
> 
> Use the helper to do the MKCOL (or create the collections in the underlying
> repository, if you have access).
> 
> Workaround #2:
> Don't author in spaces where you don't already have an existing collection.

A non technical user that is used to using a given application in a certain
way is not going to be happy with any of that. Forced migration of large
user populations to doing things differently is a big headache even when
the new ways are more convenient than the old ones. Forced migration of
large user populations to such awkward workarounds is pretty much out of
the question.

> Since my personal use of HTTP/1.1 authoring tools has always been in an
> existing collection, it seems to me that these workarounds would be
> satisfactory.  Do you have real-world use scenarios in which these scenarios
> would not work?  If so, are these common use cases, or rare use cases?

I don't have any statistical data how commonly people use PUT-based
applications for web publishing, and how many of them have the habit
of creating directories in this way. Nor do I have the slightest idea how
one might be able to get such data in a reliable way. Surely, ftp is more
popular, but given the large number of PUT-enabled applications and the
convenience of using the same namespace for both viewing and uploading, I
tend to believe *some* people are using it. If a large hosting operation
has even a small percentage of its users relying on that functionality,
they may run into a serious headache if they suddenly disable it. I think
that breaking existing applications (and even more so breaking people's
work habits) is something that should be avoided unless it is truly
necessary or proven to be a non-issue (not the other way around).

I agree that this whole thing is not such a "big" issue, but not for the
same reason as you. The thing that makes it pretty benign is that nothing
at all will happen to WebDAV interoperability if this requirement would
be ignored. So for anyone who is primarily interested in getting things
to work, the choice is between zero loss on one hand and some (no matter
how small) loss on the other. So the main problem I see here isn't that
applications will really get broken, but that you have a part of the
protocol whose main function is to encourage non-compliance with that
protocol, and this tends to open the way for further non-compliance.
It isn't a good thing.

> Since RFC 2518 is now a Proposed Standard, you would have to provide an
> extremely compelling argument, backed up with significant documentation,
> that this document is causing common and widespread interoperability
> problems for it to be modified, and re-issued.  At present, it is my opinion
> that you have not done so.

I do not consider this my personal problem. I'm basically just submitting
a bug report. If you want to call it a feature, then fine. I feel like my
moral duty was done. This particular bug, by the way, is very easy to fix.
Assuming you want minimal disturbance to the protocol, then all it takes
is changing one MUST to a SHOULD.

You don't say anything about the DELETE issue. Do you think that it's a
kosher thing to send 207 responses that are really error responses to
(non-WebDAV) HTTP/1.1 clients? Some people previously suggested that since
HTTP/1.1 says that a 2xx response to a DELETE is not an absolute commitment
to having the resource deleted, then you are allowed to always send a 2xx
regardless of the outcome. This is a distorted interpretation of HTTP/1.1.
It says that a 2xx response to a DELETE indicates the acceptance of the
request as such, and that there might still be a chance that this request
will be rejected in the future due to the possible existence of further
control mechanisms such as human intervention. This is not the same as
responding with a 2xx in cases where the server fully and clearly rejects
the request, and nobody in his right mind will design a purely HTTP/1.1
server to behave in this way.

This particular DELETE problem can also be given a relatively simple
pointwise solution: Just make it a MUST for the client to submit a
Depth header, so the client would be actually identifying itself as
a WebDAV client in this way, and the server would be allowed to use
HTTP/1.1 semantics for the DELETE if a Depth header is not included.
While it might not be elegant to use a Depth header to convey information
that isn't related to a requested depth, it will work.

What seems to really be going on here, is that some of you guys are
basically saying: Look, we have this new protocol that is designed
the way we think it should be, and we don't care all that much about
other protocols and existing applications. So, unless someone *proves*
that our protocol "is causing common and widespread interoperability
problems" we don't really mind sending bogus response codes and breaking
some functionality. People should just upgrade to use our new stuff.

This is simply a rude (if not arrogant) approach, and it has the potential
to backfire in some counter-productive ways. You seem to consider it an
axiom that people will just accept your approach, and will blindly implement
whatever you write. This is NOT how the real world works. As an implementor,
*I* may decide that there are currently more HTTP/1.1 clients than there are
WebDAV clients, and since I want to support both, I will simply ignore your
prohibitions on PUT (which wouldn't cause any real problem) and also keep
my implementation of DELETE compliant with HTTP/1.1 (if I'm forced to lie
to some clients about the outcome, then I might choose to lie to the
WebDAV client rather than to the HTTP/1.1 client).  At this point some
important WebDAV functionality is lost, because the 207 response mechanism
to a DELETE carries important information. Now, it is sufficient that
*some* implementations would do that (need not be most) in order to break
the ability of WebDAV clients to count on this mechanism to work properly
(and some client implementors might even guess this potential problem in
advance, and will not count on this portion of the protocol to get implemented).
And then clients would need to use workarounds (for example, they can followup
on any DELETE with a PROPFIND to find out what really happened). At this
point of the cycle, there is no longer any motivation for server
implementors to implement this part of the protocol, so ooops, before
you know it we just lost a piece. 

Commercial application vendors can sometimes break older applications
(even in a premeditated intentional way) in order to force people to
upgrade to the latest generation. In an open standards environment, you
simply can't do that, because you don't have the muscle. So protocols
should try to be friendly, or else it's their own value that is getting
diminished.

I think there are more problems with the current protocol than you might
realize at this point. The MOVE/COPY issue, that had been discussed in a
number of recent posts to list, seems like a bigger thing. Particularly,
since the primary WebDAV client in existence (Microsoft web folders)
seems to be built on the assumption that MOVE/COPY work differently
than what the protocol says. Regardless of who's fault this is, anyone
that would currently implement a server that does what the protocol says
it should do (for these requests) will have a serious problem on his hand.
So I tend to believe that, one way or the other, there will be some
changes made to this protocol in the not to distant future, and I think
that at that opportunity the PUT/DELETE issues should also be resolved.


Yoram

Received on Tuesday, 20 April 1999 12:50:36 UTC