- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 05 Feb 2008 13:52:12 +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: >> So what kind of side effect would be updating a hit counter GIF? Or >> updating a list of "top referrers"? > > If the resource triggers the modification, then GET is misused, if it's > a server configuration (filter, automatic log analysis), then the > resource is not responsible for those side effects. That seems at best fuzzy to me. The distinction you mentioned seems to be an implementation detail, so not really relevant... >> 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> > > I know about the definition of Location, but here we are not > redirecting, just indicating the URI of the main newly created resource, > and it can be done by only exposing it in the response entity (there is > no MUST there). Again? Why would you want to return a Location header in PUT->201? I don't think servers do return it today. >>>> - 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. > > But in this case it may apply to another URI than request URI... It should apply to the Request-URI. BR, Julian
Received on Tuesday, 5 February 2008 12:55:57 UTC