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

RE: Dereferencing HTTP URIs (redux?)

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 5 Sep 2007 13:48:30 -0500
Message-Id: <p0623090ec3047a44ec0b@[]>
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "W3C-TAG" <www-tag@w3.org>

>>  1) Re-defining the semantics of a core element in a protocol
>>  that's been widely deployed for more than a decade will
>>  surprise and displease some people.
>On the whole I'd like to feel that where we end up would be a legitimate
>use pattern for an existing facility.

Although I have been a rather harsh critic of the range-14 decision 
in the past, please allow me to suggest a way to describe it which 
makes it exactly into that, i.e. a legitimate use pattern for an 
existing facility. (Perhaps this will simply be a restatement of the 
TAG's own thoughts when coming to this decision; if so, I apologize 
for the repetition, but observe that it took me a long time to 
reconstruct this chain of thought.)

The situation in which this arises is where a URI is thought of by 
its owner - who is also, we will suppose, the agent who has control 
over the http endpoint to which it resolves - as denoting a 
non-information resource. What can this agent possibly do, when 
handed an http GET for this URI? If it simply returns some 
representation (in the REST sense) of a resource, then this must be 
an information resource, so cannot be the intended denotation. On the 
other hand, it seems churlish and unhelpful, and possibly wrong, to 
return an error code, as the URI does indeed denote something. 
Putting myself in the place of such an agent, therefore, I would wish 
to return some useful information about the referent, but without 
implying that the resource which is the source of this information is 
itself the referent of the URI sent to me. On the other hand, this 
information source is indeed a resource itself, so must have a URI of 
its own; and, its being an information resource, this URI does indeed 
denote it, so cannot be the URI which originated the request which 
has put me into this quandary. Given all this, then, the simplest and 
most useful thing I can do, it seems, is to send back the information 
that I have as a response to the request, but also to indicate that 
it comes not from the resource denoted by the original URI, but from 
a different resource with its own URI, to which in fact I will 
re-direct the GET request precisely so that it can be successfully 
responded to; thereby letting the requestor know that (1) the URI 
they sent me denotes something, (2) it does not denote this 
information resource, and (3) which URI does denote it. This is about 
the best I can do under the circumstances.

Seen in this way, the 303 is not so much a 'signal' to the requesting 
agent that the resource in question is, or might be, a 
non-information resource - a signal which seems arbitrary, ad-hoc and 
potentially confusing - but rather simply as an acknowledgement of 
the fact that a non-information resource cannot *possibly*, by virtue 
of its very nature, return a direct response to a GET request. It is 
the only rational move that a responding agent can make under the 
circumstances, and still cleave to the global assumptions that (1) a 
URI which retrieves a response from a resource must also denote that 
resource, which must therefore be an information resource, and (2) a 
URI which denotes anything at all should not return an error HTTP 

If this is more or less right, I think that this way of *explaining* 
the decision might be helpful for many readers, as it makes the 
decision seem less arbitrary.  It was for me, at any rate.

IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Wednesday, 5 September 2007 18:48:46 UTC

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