- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 05 Feb 2008 12:13:59 +0100
- To: Yves Lafon <ylafon@w3.org>
- CC: Stefan Eissing <stefan.eissing@greenbytes.de>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Yves Lafon wrote: > I agree that even a GET might have side effects, but no "direct" ones. > By "direct" I mean relative only to the processing of the HTTP request > by the resource. ie: doing a GET on a resource X may generate a log > entry (and this log entry may be addressable), but it's a global server > action not a resource one. So what kind of side effect would be updating a hit counter GIF? Or updating a list of "top referrers"? >> - a 201 response informs the client that "a" resource has been created >> (maybe more) >> - a Location header informs the client of the URI of this new resource >> (if missing the URI is the one of the request???) > > As the URIs should be in the entity of the response, the logic of > !Location => request URI is wrong. Disagree. Why would you send a Location header for a successful (initial) PUT to a URI? Remember: "The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource." -- <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30> >> - a ETag header on the response indicates the current value of the >> entity tag for this requested variant (request uri or location) > > How does an ETag sent with a 201 differs from one sent with a 200 and a > Content-Location? It should never differ, and only depend on the Request-URI + those request headers that select the variant. > ... BR, Julian
Received on Tuesday, 5 February 2008 11:14:23 UTC