- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 09 Jan 2014 17:08:47 +0100
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- CC: Henry Story <henry.story@bblfish.net>, Mark Nottingham <mnot@mnot.net>, Tim Berners-Lee <timbl@w3.org>, TAG List <www-tag@w3.org>, Arnaud LeHors <lehors@us.ibm.com>, Eric Prud'hommeaux <eric@w3.org>, Yves Lafon <ylafon@w3.org>, Philippe Le Hégaret <plh@w3.org>, Peter Linss <peter.linss@hp.com>, "Appelquist Daniel (UK)" <Daniel.Appelquist@telefonica.com>
On 2014-01-09 17:04, Henry S. Thompson wrote: > Julian Reschke writes: > >> On 2014-01-09 12:57, Henry S. Thompson wrote: >>> Right -- to short-circuit this, in the TAG f2f this morning, I offered >>> the following paraphrase for the 2xx proposal: >>> >>> A 2xx response code signals all and only the short-circuiting of a >>> 303 response, with the content of what a GET to the Location header >>> of the 303 would have had, and a Content-location header giving what >>> would have been the Location of the 303. >>> >>> So no new 'semantics', in the sense that whatever you believe 303 >>> means wrt what the relation between what you originally asked for, and >>> what you _eventually_ get, holds for 2xx between what you originally >>> asks for and what you get _immediately_. >>> ... >> >> I don't believe a new 2xx works for this case. >> >> Existing clients will interpret an unknown 2xx as 200 (at least that's >> what they should do), so they would interpret the response as being >> for the request-URI, not something else. > > Why, if there's a Content-location header? They are supposed to > understand this wrt conneg, right? Content-Location just indicates that there is a more specific URI, but it doesn't change the fact that you got a representation of the resource identified by the request-URI. (see <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#header.content-location>) Best regards, Julian
Received on Thursday, 9 January 2014 16:09:20 UTC