- From: WJCarpenter <bill@carpenter.ORG>
- Date: Tue, 21 Sep 1999 16:06:51 -0700
- To: w3c-dist-auth@w3.org
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