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.

I understand, but I think this explanation covers that case. It does 
not say that a 303 response means anything other than, well, a 
redirect. I agree that this does not allow you to infer, from getting 
a 303, to the conclusion that your URI denotes anything in 
particular. What it does do is purely negative: it *avoids* what the 
TAG wants to be a valid inference, which is that getting a 200 
response means that the denoted resource is indeed an information 
resource. And its the most informative way to avoid that within the 
current HTTP code framework.

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

Yes, well, maybe I need to change that. Sigh. Can't win them all, I guess.

Pat

>
>-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


-- 
---------------------------------------------------------------------
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:54:23 UTC