- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 5 Oct 2009 22:31:25 -0700
- To: Brian Smith <brian@briansmith.org>
- Cc: "'Mark Nottingham'" <mnot@mnot.net>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Robert Brewer'" <fumanchu@aminus.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
On Oct 5, 2009, at 9:58 PM, Brian Smith wrote: > Mark Nottingham wrote: >> I don't think a new issue is necessary; IMO it's a stretch to say >> that >> the 2616 text requires servers to have separate URIs for different >> variants, and certainly that wasn't in 2068 (see issue text). > > I don't get what you mean. Are you saying it is OK to use the same > Content-Location for multiple variants of the same resource? If so, > then > what is the point of Content-Location? And, in particular, what is > the point > of saying that servers SHOULD return Content-Location when there are > multiple variants, if the Content-Location of those variants could > all be > the same as the Request-URI? Content-Location is for identifying the resource for which the message payload is a representation. It does not exist for the sake of caching. It will not go away even if caching no longer mentions it, the spec no longer refers to variants, and the requirements associated with variants are removed. Cache invalidation after a successful PUT, POST, or DELETE is a simple optimization. It is used in practice for the request URI. I don't know if it is used in practice for a Content-Location that does not match the request URI. Maybe we should check that. IIRC, that was a late addition to HTTP/1.1. The base-setting effect was for MIME, MHTML, and message archival. The only thing we can change is that it does not apply for HTTP. So, please, if you have specific changes to the document, then be specific about which sentences need to be removed or fixed. Please stop ranting about removing the field altogether, since all that does is interfere with seeing what needs to be changed in the draft. ....Roy
Received on Tuesday, 6 October 2009 05:31:44 UTC