- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 16 Mar 2014 06:39:00 +1100
- To: Jonathan A Rees <rees@mumble.net>
- Cc: Eric Prud'hommeaux <eric@w3.org>, Tim Berners-Lee <timbl@w3.org>, TAG List <www-tag@w3.org>, Arnaud Hors <lehors@us.ibm.com>, 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 14 Mar 2014, at 12:45 am, Jonathan A Rees <rees@mumble.net> wrote: > >> First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location. > > > > As you point out below, the semantics we want involve a redirect, specifically "I can't give you X but I can give you Y which describes it." > > But it's not really a redirect; the semantics you want are "you asked for that, but I'm giving you this." That's 200 with a Content-Location, because the resource *is* making an assertion about something, even if it has a separate identity. > > p2 3.1.4.1 #4 "If the response has a Content-Location header field and its > field-value is a reference to a URI different from the effective > request URI, then the sender asserts that the payload is a > representation of the resource identified by the Content-Location > field-value. " > > In the 209-like scenario the payload would *not* necessarily be a representation of the resource identified by the Content-Location field-value. Or equivalently, the sender might not want to make such a warrant. > > So I don't think your suggestion to involve Content-Location in this discussion is appropriate. > > Not that I'm a fan of 209, but I like using Content-Location in this situation even less. Can you say a bit more about why that wouldn’t be the case? -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 15 March 2014 19:39:38 UTC