- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 28 Nov 2007 14:06:52 -0600
- To: ht@inf.ed.ac.uk (Henry S. Thompson)
- Cc: public-awwsw@w3.org
>-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >First, let's be careful about the preconditions for the 200 vs. 303 >question. > >1) A client issues an HTTP GET request for a URI *U* which identifies > a resource *T* to a server *S* > >2) *S* generates one of two responses: > > 2a) > HTTP/1.1 200 OK > Content-type: xxx > . . . > > [a representation *R*] > > 2b) HTTP/1.1 303 See Other > . . . > Location: [a URI *Uprime*] > > A further GET request is issued, for *Uprime*, to which the > response is > > HTTP/1.1 200 OK > Content-type: yyy > . . . > > [a representation *Rprime*] > > > * What can you infer in case (2a)? > > *R* is a representation of the resource *C* identified by *U*. Two questions. (1) Why isn't it a representation of *T* ? (See (1) above) (2) You are here, I presume, using "representation" in the REST/TAG sense? If so, I would note that this word is used in the wider world in a variety of senses, most of which have almost no connection with the REST/TAG sense. > > * What can you infer in case (2b)? > > *Rprime* is a representation of *Cprime*, the resource identified > by *Uprime*. *Rprime* is _not_ a representation of *C*. Again, why C rather than T? But in any case, in several of the broader senses of "representation", it might well be a representation of it. It might, for example, be an RDF description of it. Or even an English description, or a jpeg picture (or all of these). All of these can be called "representations" of something (though no, of course, in the REST/TAG special sense of "representation"). I'm assuming here that in this case, the resource "identified" by the first URI is a non-information resource, of course. That is, that you allow "identifies" to include "denotes" as one kind of identification. Is that right? It is of course notoriously hard to know what anyone means when they say "identifies", so this assumption may be mistaken. >That's as far as we can go without going beyond 2616. Note in >particular that we absolutely _cannot_ infer from a 303 that the URI >in the Location header of the response identifies a description of or >metadata about the resource identified by the original URI. It's >perfectly possible, indeed likely, that there are plenty of uses of >303 on the Web today which do not admit that interpretation, and >there's no way to rule out the appearance of URIs which provoke such >responses as e.g. the subjects of SW sentences. > >To get something stronger than the negative conclusion which 303 gives >us, I think we should look seriously at asking for a new response code >in the new HTTP RFC: Either a 207, meaning explicitly "The >representation returned herewith represents a description of the >resource identified by the requested URI (i.e. it is _not_ a >representation of the resource itself)" Please explain it better than this. In the wider world, a description IS (one kind of) a representation. In a large part of the wider world, a formal description is a canonical example of a representation. But apart from griping about terminology, this doesn't solve the ambiguity-of-URIs issue that gave rise to this whole business in the first place. We shouldnt lose sight of the fact that the whole problem arises because we want to know what it is that a **URI** denotes; not what a URI+(an http response code) denotes. >, or a 308, meaning explicitly >"No representation of the resource identified by the requested URI is >available. The accompanying Location response header gives a URI >which identifies a description of that resource." 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, 28 November 2007 20:07:10 UTC