- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 28 Sep 2009 00:18:30 -0700
- To: Brian Smith <brian@briansmith.org>
- Cc: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Robert Brewer'" <fumanchu@aminus.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
On Sep 27, 2009, at 11:59 PM, Brian Smith wrote: > Julian Reschke wrote: >> Brian Smith wrote: >>> First, "when it is different than the request resource's URI" is >>> unnecessary and wrong. Having a Content-Location that is the >>> same as the request URI is valid and is actually the only safe >>> use of Content-Location. >> >> What use would that be? (assuming we're talking about GET) > > Exactly. Content-Location doesn't have any interoperable uses in > HTTP. My > point is that Content-Location is generally safe only when Content- > Location > = Request-URI, but then it is useless, except for its misuse in > AtomPub (See > RFC 5023 to see how Content-Location is used in AtomPub). It is being used correctly by AtomPub. The purpose of the field is to support MIME encapsulation, not HTTP, so the fact that it has only one remaining usage in HTTP (due to browser bugs) should be no big surprise. The section should not say "when it is different than the request resource's URI" because it is useful for a response to a non-GET method that wants to indicate that this body is what you would have received in a 200 response if the request had been a GET on the content-location URI. In other words, it saves the client from having to make a subsequent request for the current state if the client can trust the server's response, which is almost always true for non-GET methods and especially when the Content-Location does match the requested URI. ....Roy
Received on Monday, 28 September 2009 07:19:07 UTC