- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 5 Sep 2007 13:48:30 -0500
- To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
- Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "W3C-TAG" <www-tag@w3.org>
>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 18:48:46 UTC