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

Re: Dereferencing HTTP URIs (redux?)

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Wed, 5 Sep 2007 16:36:32 -0400
Message-Id: <69AC4C0E-52CA-4BFC-8E99-80320EBAA74A@gmail.com>
Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "Mark Nottingham" <mnot@yahoo-inc.com>, "W3C-TAG" <www-tag@w3.org>
To: Pat Hayes <phayes@ihmc.us>

Hi Pat,

This would be a reasonable explanation if a 303 always meant that you  
were trying to dereference a non-information resource (usual sense of  
"non-" - something that is not an information resource). However, the  
TAG claims otherwise - that, from a 303 , you can only understand  
that a 200 was not returned, and that is therefore the case that you  
don't know it is an information resource.

http://www.ihmc.us/users/phayes/PatHayes notwithstanding.


On Sep 5, 2007, at 2:48 PM, Pat Hayes wrote:

>> Mark:
>>>  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.
>> Stuart:
>> 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 code.
> 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.
> Pat
> -- 
> ---------------------------------------------------------------------
> 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 20:36:43 UTC

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