Re: Why MKCOL/PUT can't automatically create ancestor collections?

Sorry about the delay on the response...

"Jim Amsden" wrote:
> I think the reasoning was the same for PUT, PROPPATCH, etc. You don't
want
> the server creating namespaces as the side effect of an operation. MKCOL
> and DELETE make namespace manipulations explicit. This prevents
erroneously
> typed URLs from creating spurious namespaces.
>
I don't understand how making these explict will cause anything other than
forcing a bunch of overhead.

Take for example, in a client app the user decides to do a "Create file
with path: 0/1/2/3/4/5/6/7/8/9/foo.c"

The client app has the options of:
a) Performing the PUT and seeing what the status code is.  If it is 409,
then client can then attempt a MKCOL on each parent collection until one is
successful.  Once successful, then traverse back down the path and perform
each MKCOL, then perform the PUT.
b) Performing many PROPFIND's (either starting from the root or from the
file resource), then perform a MKCOL for each collection and then finally
the PUT.

 Does the client app have to prompt the user whether each collection should
be created?  How does forcing the client app to perform all these
operations prevent erroneously typed URLs from spurious namespaces?

My app does a large amount of *implicit* namespace creation and I'd like to
do a simple:
     PUT /0/1/2/3/4/5/6/7/8/9/foo.c HTTP/1.1
and have the parent collections implicitly created if they don't exist but
the spec forces the overhead mentioned above.

Could this server behavior be advertised using the DAV header with
something like "auto-collections"?  Then if one so desired, removing the
requirement that "PUT operation creates a new non-collection resource all
ancestors MUST already exist" (RFC2518 8.2.2) if auto-collections is
supported and making the method MKCOL an optional feature.
I'm not sure this requirement is consistent with DELETE, MOVE, and COPY:
which can perform a large amount of namespace manipulation in one METHOD
(namely on a parent collection).  There is no way to guarantee that the new
target destination URL has not been erroneously typed other then by user
inspection after the fact (or by client app prompting, do we ever pay
attention to those ;-)

Thoughts?

Thanks,
Steve

Received on Monday, 18 June 2001 09:44:17 UTC