RE: Clarification on MKCOL needed

I like it.

> -----Original Message-----
> From: bill@carpenter.ORG [mailto:bill@carpenter.ORG]
> Sent: Tuesday, September 21, 1999 4:07 PM
> To: w3c-dist-auth@w3.org
> Subject: 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 22:09:57 UTC