Re: A new HTTP response code say 209

* David Sheets <kosmo.zb@gmail.com> [2014-01-09 13:21+0000]
> 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:
> >>
> >>> It is a bad idea to put semantics into media types. Media types are
> >>> there to help interpret the representation coming back from the
> >>> resource, not for describing the resource itself ( since after all
> >>> the same resource could have a number of different representation in
> >>> different formats, as we do in RDF land regularly )
> >>
> >>> ...
> >>
> >>> What is wanted is something that does what 303 does, but returns the content immediately.
> >>
> >> 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_.
> >
> > Sounds good. I think one should perhaps also speak about the meaning of the
> > headers. Should they not also be interpreted as if they had been returned
> > on a request on the Content-Location URL had it been requested directly?
> >
> > This is important for the Web-Linking RFC, for example
> >
> >   http://tools.ietf.org/html/rfc5988#section-5.1
> >
> > [[
> >  By default, the context of a link conveyed in the Link header field
> >    is the IRI of the requested resource.
> > ]]
> 
> This may be a bit mad but...
> 
> 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.

Cool idea, my guess is that it would stretch libraries a bit out of
shape. In particular, it might be hard to persuade browser libraries
like Ajax to parse the contained HTTP transaction so you'd have to
roll that bit on your own.

The semantics would be a bit specialized in that HTTP would, for the
first time, specify the behavior of a particular media type. That spec
might be interesting indeed, for instance, would an intervening cache
be permitted to cache and serve the outer and inner messages?

My money's on Henry's 2xx = 303+final payload, but this is probably
worth poking at.


> David
> 
> > Btw, I wonder if a 3xx code would not be more
> > appropriate. 3xx indicates to all that we are in
> > the redirect space, which may be an important intuition worth
> > holding onto.  Anyway, whatever is decided it would be
> > a great step forward.
> >
> >
> >>
> >> ht
> >> --
> >>       Henry S. Thompson, School of Informatics, University of Edinburgh
> >>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
> >>                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
> >>                       URL: http://www.ltg.ed.ac.uk/~ht/
> >> [mail from me _always_ has a .sig like this -- mail without it is forged spam]
> >
> > Social Web Architect
> > http://bblfish.net/
> >
> >

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 9 January 2014 13:46:43 UTC