Re: Review of new HTTPbis text for 303 See Other

On Jul 16, 2009, at 3:01 AM, Richard Cyganiak wrote:

> 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.

I agree, and this works very well for me also. If this is what the  
specs have meant all along, then I have been guilty of a multi-year  
misunderstanding. So, the whole HTTP thing is about servers and URIs,  
and 'resources" are simply the things that the URIs refer to, and they  
play no operational role in the protocol machinery. The URI resolves  
to a server, not to a resource.

Yes, I like that. Can one read the whole spec consistently with this  
picture, I wonder?

Pat

>
> 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
>>
>>
>>
>>
>>
>
>
>

------------------------------------------------------------
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 11:50:44 UTC