W3C home > Mailing lists > Public > www-tag@w3.org > February 2014

Re: A new HTTP response code say 209

From: Reto Gmür <reto@gmuer.ch>
Date: Thu, 13 Feb 2014 18:01:39 +0100
Message-ID: <CALvhUEV-dg_trK24zvHFkw3u8_ZiTMM=FG4h7YJK_fhGCeH=4g@mail.gmail.com>
To: David Sheets <kosmo.zb@gmail.com>
Cc: Henry Story <henry.story@bblfish.net>, Henry Thomson <ht@inf.ed.ac.uk>, Mark Nottingham <mnot@mnot.net>, Tim Berners-Lee <timbl@w3.org>, TAG List <www-tag@w3.org>, Arnaud LeHors <lehors@us.ibm.com>, "Eric Prud'hommeaux" <eric@w3.org>, 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 Thu, Jan 9, 2014 at 2:21 PM, David Sheets <kosmo.zb@gmail.com> 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:
> >>
> >>> 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.
>

Clients that treat 2xx as a 200 might have difficulties with this
media-type. But if this would be the body of a 303 response clients that do
not support this feature will simply redirect and ignore the message body.
With this approach no new response code would be needed but the response of
303 should no longer be constrained to be "a short hypertext note".

Cheers,
Reto


>
> 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/
> >
> >
>
Received on Thursday, 13 February 2014 17:02:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:01 UTC