Re: A new HTTP response code say 209

On 01/09/2014 09:58 AM, David Booth wrote:
> 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?

Another possible approach (instead of a 209 code) might be to return a 
300, 301, 302 or 307 code as usual, but include a multipart body with a 
part that contains the entirety of 
the-response-that-you-would-have-gotten if the client had repeated the 
request on the Location URI.

David

Received on Thursday, 9 January 2014 15:15:35 UTC