Subject: Clarification on MKCOL needed

From: "Brian Stiles" <[email-masked]>
Date: Fri, 10 Sep 1999 14:56:20 -0700

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?

--
Brian Stiles

---

From: Greg Stein <[email-masked]>
Date: Fri, 10 Sep 1999 15:57:52 -0700

> allowing clients to specify the name)?  Put another way, how can a

It can't. MKCOL is defined as creating the collection specified by the
Request-URI. If your server doesn't do that, it it isn't MKCOL :-)

Is it possible for you to create (internally) the server-specified
collection and then somehow link/alias the Request-URI to point to the
new collection?

If you have a custom client, then you can define a method such as
"STARBASE-MKCOL" which is modelled after MKCOL, but returns a Location
header with the true URI. Another alternative is to return the
"next-collection-name" as a property of the parent collection; this has
transactional problems, though (e.g. what happens if two clients request
the property and then use it in MKCOL?)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: Brian Stiles <[email-masked]>
Date: Fri, 10 Sep 1999 16:47:53 -0700

Thanks for the quick response.

> collection and then somehow link/alias the Request-URI to point to the

It's problematic because we are trying to make use of a legacy
repository that has some inconsistencies with the WebDAV model and we
are trying not to modify the repository code.  In particular, if you use
the repository-assigned ID's of the objects in the repository for the
URI, then you can have proper URI's for each object, but you can't
create new collections with MKCOL for the aforementioned reason.  If you
use the user-assigned name of each object in the repository, you can't
have proper URI's for each object in the repository because there can be
multiple objects in one collection that have the same name.

After thinking about your suggestion, it appears we have two choices. 
We could use the user-assigned names of collections in the MKCOL
request-URI and also assign the new collection a URI based on the
repository-assigned ID's.  Or, perhaps a better approach would be to
consider it a flaw in the repository that two objects in the same
collection can have the same name and just disallow access via WebDAV to
all but one of the objects with the same name.

> the property and then use it in MKCOL?)

That is problematic indeed in our case.  I think I'd rather bend my
product to work with the protocol than extend the protocol to work with
my product.

Thanks again.

-- 
Brian Stiles