W3C home > Mailing lists > Public > www-tag@w3.org > December 2007

Re: Alternative to 303 response: Description-ID: header

From: Laurian Gridinoc <laurian@gridinoc.name>
Date: Wed, 5 Dec 2007 12:53:54 +0000
Cc: Tim Berners-Lee <timbl@w3.org>, "Sean B. Palmer" <sean@miscoranda.com>, "David Booth" <dbooth@hp.com>, www-tag@w3.org
Message-Id: <02DE11C5-9F9A-4C58-ADA1-6FBB319DEBAA@open.ac.uk>
To: ht@inf.ed.ac.uk (Henry S. Thompson)


Supposing that a 30x response is not explicitly disallowed to have a  
…what about a 30x (let's say 306) which means that the description is  
in the response body, while the Location points to a  representation?

It will keep old browsers happy via the redirect, while you get the  
description without any additional request.

Laurian Gridinoc
PhD Student, Knowledge Media Institute

On 5 Dec 2007, at 11:55, Henry S. Thompson wrote:
> I proposed adding a 207 response code along these lines on another
> list [1]:
>  "To get something stronger than the negative conclusion which 303
>   gives us, I think we should look seriously at asking for a new
>   response code in the new HTTP RFC: Either a 207, meaning explicitly
>   "The tag:representation returned herewith represents a description
>   of the resource identified by the requested URI (i.e. it is _not_ a
>   tag:representation of the resource itself)", or a 308, meaning
>   explicitly "No tag:representation of the resource identified by the
>   requested URI is available.  The accompanying Location response
>   header gives a URI which identifies a description of that resource.
>  "The 207 approach has the advantage that it does not require two
>   round-trips.  The 308 approach has the advantage that it provides a
>   URI for the description.  We _could_ mandate the provision of a
>   Content-Location response header when a 207 is given, but that is I
>   guess a bit weird. . ."
> ht
> [1] http://lists.w3.org/Archives/Public/public-awwsw/2007Nov/0011.html
Received on Wednesday, 5 December 2007 18:25:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:54 UTC