W3C home > Mailing lists > Public > public-awwsw@w3.org > November 2007

Re: 200 vs. 303 vs. ??? (was Re: Raw minutes of meeting 2007.11.27)

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 28 Nov 2007 14:06:52 -0600
Message-Id: <p06230903c3737662608b@[]>
To: ht@inf.ed.ac.uk (Henry S. Thompson)
Cc: public-awwsw@w3.org

>Hash: SHA1
>First, let's be careful about the preconditions for the 200 vs. 303
>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."

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:05 UTC