Re: Dereferencing HTTP URIs (redux?)

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.

-Alan

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