atom feed151 messages in org.w3.public-lodRe: Is 303 really necessary?
FromSent OnAttachments
68 earlier messages
Michael HausenblasNov 5, 2010 2:29 am 
Leigh DoddsNov 5, 2010 2:34 am 
Leigh DoddsNov 5, 2010 2:37 am 
Leigh DoddsNov 5, 2010 2:42 am 
William WaitesNov 5, 2010 2:54 am 
Ian DavisNov 5, 2010 2:57 am 
NathanNov 5, 2010 3:05 am 
NathanNov 5, 2010 3:12 am 
Ian DavisNov 5, 2010 3:17 am 
Ian DavisNov 5, 2010 3:24 am 
NathanNov 5, 2010 3:34 am 
Ian DavisNov 5, 2010 3:40 am 
NathanNov 5, 2010 3:57 am 
Ian DavisNov 5, 2010 3:59 am 
Ian DavisNov 5, 2010 4:02 am 
NathanNov 5, 2010 4:15 am 
Mischa TuffieldNov 5, 2010 4:47 am 
Norman GrayNov 5, 2010 5:11 am 
Dave ReynoldsNov 5, 2010 5:38 am 
NathanNov 5, 2010 5:52 am 
NathanNov 5, 2010 5:57 am 
Vasiliy FaronovNov 5, 2010 6:00 am 
Vasiliy FaronovNov 5, 2010 6:33 am 
NathanNov 5, 2010 7:18 am 
David WoodNov 5, 2010 7:18 am 
Pat HayesNov 5, 2010 7:27 am 
Ian DavisNov 5, 2010 8:12 am 
Kingsley IdehenNov 5, 2010 8:18 am 
NathanNov 5, 2010 8:40 am 
Kingsley IdehenNov 5, 2010 9:36 am 
Pat HayesNov 5, 2010 10:29 am 
Kingsley IdehenNov 5, 2010 10:31 am 
NathanNov 5, 2010 10:37 am 
Hugh GlaserNov 5, 2010 10:50 am 
David BoothNov 6, 2010 1:42 pm 
Norman GrayNov 6, 2010 3:45 pm 
Kingsley IdehenNov 6, 2010 4:08 pm 
David BoothNov 7, 2010 10:27 pm 
David BoothNov 7, 2010 10:28 pm 
Tore ErikssonNov 7, 2010 11:18 pm 
Toby InksterNov 8, 2010 12:37 am 
Toby InksterNov 8, 2010 2:11 am 
David BoothNov 8, 2010 6:40 am 
David BoothNov 8, 2010 6:42 am 
Norman GrayNov 8, 2010 7:51 am 
Toby InksterNov 8, 2010 8:03 am 
David BoothNov 8, 2010 12:34 pm 
Lars HeuerNov 8, 2010 1:17 pm 
David BoothNov 8, 2010 1:35 pm 
Dave ReynoldsNov 8, 2010 1:50 pm 
33 later messages
Subject:Re: Is 303 really necessary?
From:David Wood (
Date:Nov 5, 2010 7:18:47 am

Hi all,

This message is an attempt to summarize my position in relation to the points
made by others. I hope it is useful to the discussion. A new approach to the
problem is discussed at the end of this message that proposes deprecating the
303 for use in Linked Data (only) in favor of a new HTTP response code. The new
response code would state "The URI you just dereferenced refers to a description
of a resource that may be informational, physical or conceptual. The
information you are being returned in this response contains an RDF description
of the resource you dereferenced."

1) Kudos to Ian for starting the most engaging discussion on this list in many

2) I think we all agree that the SemWeb/Linked Data usage of the 303 is a hack,
non-optimal and is worthy of reconsideration *presuming* that we can change the
way a lot of people use the Web. I'm an optimist, so I'm willing to have a go.

3) Nathan (correctly, IMO) summarized the core problems with the 303 when he

On Nov 4, 2010, at 16:23, Nathan wrote:

</thing> -> 303 -> </doc>

(1) Many automated clients that make assertions about URIs treat HTTP as a
blackbox, thus are still saying </thing> a :Document . (original problem not

(2) Many Humans are clicking on </thing> getting the </doc> URI in their address
bar then using that instead, saying that </doc> a :Thing . (new problem)

(3) Network effect of 303 (2 requests) vs 200 (single request), as well as
deployment considerations.

Completely leaving frag ids out of the equation, it appears (to me at least)
that new insight is that 303 isn't addressing the problem (1) and rather
introducing more (2) and (3).

David Booth's comments are similar in scope and, though he puts it differently,
agrees that the main issue is that "that many applications *will* wish to
distinguish between the toucan and its web page (or between the toucan's age and
the age of it's web page)". Indeed, the need for different URIs between a
physical (or conceptual) resource and its (informational) description is the
central issue.

4) Leigh Dodds is right to call me on the distinction between deprecating 303
and their use in Linked Data. I do not think 303 should be deprecated, but do
not think they are the best solution for Linked Data.

5) I totally agree with Michael Hausenblas when he says:

On Nov 5, 2010, at 05:29, Michael Hausenblas wrote:

It occurs to me that one of the main features of the Linked Data community is that we *do* things rather than having endless conversations what would be the best for the world out there.

6) We can't really hack at the 303 any more than we have. I explored that in
2007 and came up pretty empty:

So where does that leave us? I think that the best way out is to return a
single HTTP response for the resolution of a URI describing a physical or
conceptual resource that unambiguously states that the returned response is a
*description* of that resource.

That leaves me in agreement with Phil Archer (
when he proposed a new HTTP response code. Let's just do it! It might work
like this (using Ian's notation from

# Get an information resource: GET /doc returns a 200 (OK)

# Get an information resource with an RDF description: GET /toucan_info responds with a 210 (Description Found)

# Get a physical resource: GET /toucan_physical responds with a 210 (Description Found)

# Get a conceptual resource: GET /toucan_definition responds with a 210 (Description Found)

How does that stack up against Ian's objections to the 303? Rather well,
actually. - It returns the required information in one GET. - Multiple descriptions can be linked from a resource's URI via the returned
RDF. - A human using a browser stays at the same URI requested (and content
negotiation would still work). - It is trivial to configure a Web server to match an HTTP status code to file
extensions. - It can be implemented using a static Web server setup (one that serves just
RDF). - It does not mix layers of responsibility. - It can be used with information resources, as well as physical and conceptual
resources. - It is easy to explain to the broader community.

Disadvantages are: - W3C/IETF buy-in, time and effort required to standardize. - Server operators would have to configure their Web servers to return the
correct status code (until Web servers shipped with reasonable defaults).

All that is left is to prototype it. It doesn't seem to break curl, so that's a
start :)

[[ Macadamia:~ dwood$ curl -I http://localhost:8090/ HTTP/1.1 210 Description Found Date: Fri, 05 Nov 2010 14:15:31 GMT Server: Hacked up Web server by prototypo ]]

Regards, Dave