- From: Geoffrey M. Clemm <gclemm@atria.com>
- Date: Tue, 21 Sep 1999 15:08:10 -0400
- To: w3c-dist-auth@w3.org
Make the $0.04 (i.e. I agree with Yaron). Cheers, Geoff > To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, > > This is an old and well known issue that many people mistakenly think is > solved. > > The server is completely free to return to a PUT or MKCOL with a 200 O.k. > and throw on a location header which points to the "real name" of the new > resource while throwing away the client's proposed name. > > In practice no server I'm aware of does this and no client I'm aware of > could properly handle this. > > If memory serves this issue is already on the WebDAV open issues list. > Personally I think we should just adopt current practice which says that you > must either accept the name or reject the request but that is just my $0.02. > > Yaron > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > > I agree with you that this is a problem for all document > > management systems. > > I believe it is the most fundamental mismatch between the > > WebDAV operational > > model and the way document management systems work. It > > affects not only > > MKCOL, but all methods that result in the creation of new > > resources (COPY, > > MKREF, PUT, MKRESOURCE). > > > > It's also wound up with the requirement that WebDAV resource > > names reflect > > the collection hierarchy, which the server-generated names in document > > management systems generally do not do. > > > > Document Management Systems will probably be forced to do > > aliasing between > > client names and server names, no matter how costly and > > annoying that turns > > out to be. > > > > > > > -----Original Message----- > > > From: Brian Stiles [mailto:bstiles@starbase.com] > > > How can a WebDAV server support MKCOL if the repository the > > server is > > > built upon assigns names to newly created collections (as opposed to > > > allowing clients to specify the name)? Put another way, how can a > > > client create a collection on a WebDAV server using MKCOL if the > > > collection that gets created must be assigned a URI by the server? > > > For example, suppose that each collection is assigned an ID that is > > > unique to the database that underlies the WebDAV server and > > this ID is > > > used to identify the collection in a URI (e.g., > > > http://foo.com/121/13/4/). If a client wants to create a new > > > collection, it must issue a MKCOL request to > > > http://foo.com/121/13/4/<NEW_NAME>/ but because of the fact that the > > > server essentially controls the namespace, not the client, > > the client > > > can't know what to send for NEW_NAME. > > > > > > Am I missing some important piece of information here? I > > assume that > > > document management systems might be likely to encounter > > this kind of > > > problem. If so, has anyone dealt with it? > > > > > > Although it doesn't seem to be explicitly forbidden, I am assuming > > > that it is inappropriate for the server to ignore the name in the > > > request-URI and respond with a Location header that identifies the > > > name assigned by the server. Though this seems like a possible > > > solution, it seems contrary to the intent expressed in the spec. Or > > > am I wrong in this assumption?
Received on Tuesday, 21 September 1999 15:08:17 UTC