W3C home > Mailing lists > Public > www-tag@w3.org > July 2009

Re: Review of new HTTPbis text for 303 See Other

From: Richard Cyganiak <richard@cyganiak.de>
Date: Thu, 16 Jul 2009 10:01:41 +0200
Cc: "www-tag@w3.org WG" <www-tag@w3.org>
Message-Id: <C8B7B393-AD6F-4E0F-AD55-A8A9D1413192@cyganiak.de>
To: Pat Hayes <phayes@ihmc.us>
On 15 Jul 2009, at 18:22, Pat Hayes wrote:
>>> A 303 response to a GET request indicates that the server does
>>> not have a transferable representation of the requested resource
>
> Maybe I am misreading this. Consider an example, to help clarify. I  
> have an HTTP URI which, for reasons that need not detain us here but  
> which are set in stone, refers to a (non-information) resource, say  
> Richard Cyganiak the person. A GET with that URI resolves to an  
> endpoint which itself is (of course) a resource also, but not (of  
> course) the one that the URI denotes ("identifies"). Let us call  
> this resource R. This is the classical case that http-range-14  
> requires to have a 303 emitted to the client by R, or at least by  
> the http endpoint associated with R. (I am never quite sure of  
> exactly how the 'resource' relates to the http endpoint, but let us  
> try to ignore that issue here: the main point is that R, whatever it  
> is, is certainly not Richard Cyganiak .) Now, in this scenario, what  
> exactly is "the requested resource" in the above wording?

A good and helpful question.

So let's do a GET on http://example.com:8080/people/richard_cyganiak.

The way I see it, the requested resource is Richard Cyganiak. When I'm  
resolving the HTTP URI, a request is sent to a *server*, example.com,  
at port 8080, using the HTTP protocol, and the server responds with a  
certain status code. The HTTP interface/endpoint is the *server*, and  
not the individual resource. The resource -- the thing identified by  
the URI -- does not directly take part in the HTTP conversation. Its  
only relationship to the server is that a) the URI owner intends the  
URI to identify that resource, hence the server becomes responsible  
for answering requests to it, and b) the server holds (or not)  
representations of the resource.

This is certainly not the only possible interpretation supported by  
the language in the relevant documents, and it requires some mental  
gymnastics, but this interpretation works well for me and answers the  
"how are you going to attach an HTTP endpoint to an imaginary thing"  
argument.

Richard



> Is it R or is it Richard Cyganiak? Because I have been assuming that  
> this must mean R; but if it can mean a non-Webbish thing like a  
> person, then indeed the above makes perfect sense. In which case I  
> would only ask that the spec wording make it absolutely clear that  
> the "requested resource" need not be the resource that the URI  
> resolves to in a GET request. If, on the other hand, this is what  
> the phrase "requested resource" means, so that in my example it  
> refers to R rather than to Richard, then I object to the above  
> wording on the grounds that it is false: the 303 response should  
> *not* be taken to indicate that the server has no transferrable  
> representation of R. It may well have one (the fact is irrelevant to  
> the response) and indeed it may be able to make use of it under  
> other circumstances, as for example when resolved to by a GET using  
> a different URI. (For example, it might be important to be able to  
> discover what is 'acting for' Richard Cyganiak in these http  
> transactions, for security or trust purposes.)
>
> The basic point is that http-range-14 means that there may be  
> circumstances which have nothing whatever to do with  
> awww:representations, but which nevertheless require a server to  
> emit a 303 code; and the wording used should allow for this.
>
> Pat
>
>>> and is instead redirecting the client to some other resource
>>> for further information.
>>> then I think the objection is handled without watering down
>>> the purpose of using the status code on a GET.
>>
>> I'm happy to make this change if there are no objections, and it  
>> does make at least a few people less unhappy.
>>
>> BR, Julian
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494  
> 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
Received on Thursday, 16 July 2009 08:02:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:15 GMT