Re: Review of new HTTPbis text for 303 See Other

Pat Hayes wrote:
>
> On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote:
>
>> On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@gbiv.com> 
>> wrote:
>>
>>> That's because you happen to be reading it differently than
>>> what I was thinking when I wrote it.  The sentence is a bit
>>> ambiguous if you don't pay attention to what the second "that"
>>> means.  If it is reordered to say
>>>
>>>  A 303 response to a GET request indicates that the server does
>>>  not have a transferable representation of the requested resource
>>>  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.
>>>
>>> ....Roy
>>
>> Excellent! The rewording you give above would be fine with me - I
>> would be satisfied if HTTPbis said this, or something equivalent.
>> (because then the choice to yield a 303 can be attributed to the
>> server, and would not necessarily reflect on the nature of the
>> resource - "the server does not have" vs. "the resource does not
>> have".)
>
> Hmm, then I am puzzled. Does 303 redirection really imply that the 
> server **does not have** a transferable representation? Surely 303 
> redirection is used under other circumstances than this, circumstances 
> which have nothing whatever to do with http-range-14 and were being 
> used before the http-range-14 issue was even raised? No?
Why puzzled? It makes perfect sense.  A transportation protocol express 
the semantics of a server but not that of its resource.  At most, it 
express what the URI owner thinks about the resource denoted by the URI, 
but it is neither what the resource owner thinks nor what the resource is.

httpRange-14 is a bad design by forcing the latter semantics upon the 
URI owner. 

Xiaoshu

Received on Thursday, 9 July 2009 21:04:47 UTC