RE: Clarification on MKCOL needed

yg> The server is completely free to return to a PUT or MKCOL with a
yg> 200 O.k.  and throw on a location header which points to the "real
yg> name" of the new resource while throwing away the client's
yg> proposed name.

I don't think that's so.  (Nit #1 is that "201 Created" is the
response for a new resource.)  More importantly, RFC-2068 has specific
language about this situation for PUT (the following compares PUT to
POST):

   In contrast, the URI in a PUT request identifies the entity enclosed
   with the request -- the user agent knows what URI is intended and the
   server MUST NOT attempt to apply the request to some other resource.
   If the server desires that the request be applied to a different URI,
   it MUST send a 301 (Moved Permanently) response; the user agent MAY
   then make its own decision regarding whether or not to redirect the
   request.

I agree that a precise reading of the RFC-2518 definition of MKCOL
allows a 201 response with a LOCATION: header, but one certainly has
the impression from RFC-2518 that "MKCOL is just like PUT, but there
is no enclosed entity comprising the contents of the new resource".

If it is the intent that MKCOL differ from PUT is this fairly
significant respect, I suggest that appropriate clarifying language be 
added, but I don't particularly see why such a difference should
exist.

The RFC-2068 specified behavior for PUT could be used to solve the
problem of server-generated collection names if applied to MKCOL.
When issuing the LOCATION: header, the server could secretly keep a
record (with a timeout) of the fact that it had been sent.  A couple
hundred milliseconds later, the redirected request comes in with the
same credentials and succeeds.  If no redirected request comes within
some timeout, the collection name could be harvested.
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

Received on Tuesday, 21 September 1999 19:12:37 UTC