- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Thu, 6 Sep 2007 16:13:38 +0100
- To: "Pat Hayes" <phayes@ihmc.us>
- Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "W3C-TAG" <www-tag@w3.org>
Hello Pat, > 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. Speaking only for myself I think that what you've written is "more or less right"... yes. Thank you, Stuart -- > -----Original Message----- > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] > On Behalf Of Pat Hayes > Sent: 05 September 2007 19:49 > To: Williams, Stuart (HP Labs, Bristol) > Cc: Mark Nottingham; W3C-TAG > Subject: RE: Dereferencing HTTP URIs (redux?) > > > >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 -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Thursday, 6 September 2007 15:16:16 UTC