- From: Graham Klyne <GK@ninebynine.org>
- Date: Mon, 07 Apr 2014 11:36:44 +0100
- To: Jeni Tennison <jeni@jenitennison.com>
- CC: www-tag@w3.org
I find I'm rather uneasy about this introduction of the new 209 status code. I'm responding now, late in the day, as it's only recently I've crystallized my own view about the problem, and a possible direction for a solution. The fundamental problem I see is that the 209 response tries to (indirectly) establish semantics for the 200 response code that are not universally accepted or implemented in the Web. (The http-range-14 permathread and issues of practical use for, say, paging mentioned in Jeni's proposed response are indications of this.) Effectively, it's not fail-safe if clients assume that servers are honouring the "strict" version of 200, where in practice many do not. The view I've come to is that rather than try and indirectly refine the meaning of 200, is to leave it as it is and introduce some other mechanism to convey the desired semantics of 200 (the resource returned is a "true" representation of the identified resource). A mechanism I might favour would be to define a link relation for this; e.g. C: Get: /myresource/ C: Host: www.example.org : S: 200 OK S: Link: <http://www.example.org/myresource>; rel=represents : would be a way for a server to indicate the response returned is a representation of the requested resource, and not just some related resource. If the response is the first page, then maybe the response is something like: S: 200 OK S: Link: <http://www.example.org/myresource?page=1>; rel=represents : etc. I think this (or something like it) gives a way to deploy the stricter semantics required for agent-based web of data applications, which can be deployed as a smooth evolution of current web practices. It would not preclude use of out-of-band information to interpret "200 OK" to imply the strict representation semantics (which I would argue is effectively what happens at the moment); rather, it enables formalization of such out-of-band mechanisms (which don't scale) in a relatively simple in-band mechanism. #g -- On 05/04/2014 17:13, Jeni Tennison wrote: > TAG members, > > As discussed during our face-to-face this last week, I have put together a draft review of the draft spec for the HTTP 209 status code, at: > > https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md > > I’d appreciate a second pair of eyes before we officially forward this on to Eric Prudhommeaux as a consensual TAG review. > > Jeni > -- > Jeni Tennison > http://www.jenitennison.com/ > >
Received on Monday, 7 April 2014 10:49:17 UTC