Re: A new HTTP response code say 209

On 01/09/2014 08:21 AM, David Sheets wrote:
> On Thu, Jan 9, 2014 at 12:44 PM, Henry Story <henry.story@bblfish.net> wrote:
>> On 9 Jan 2014, at 12:57, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>>> Henry Story writes:
[ . . . ]
>>> 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_.
>>
[ . . . ]
> what if the content type of the returned representation was
> "message/http" <http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html>?
>
> In that way, you could supply both initial request and redirected
> request headers without ambiguity.

That would be very clean semantically.

What about broadening this idea to apply also to 300, 301, 302 and 307 
requests, allowing them to (optionally, if they can) bundle 
the-response-that-you-would-have-gotten if the client had repeated the 
request on the URI returned in the Location field?  I.e., treat 209 as a 
general-purpose short-circuit response?

David

Received on Thursday, 9 January 2014 14:58:48 UTC