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 15:54:12 -0500
Message-Id: <p06230903c304c64768d1@[]>
To: Alan Ruttenberg <alanruttenberg@gmail.com>
Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "Mark Nottingham" <mnot@yahoo-inc.com>, "W3C-TAG" <www-tag@w3.org>

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


>On Sep 5, 2007, at 2:48 PM, Pat Hayes wrote:
>>>>  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 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.
>>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

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