Re: Review of new HTTPbis text for 303 See Other

Pat Hayes wrote:
>
> On Jul 9, 2009, at 11:21 AM, Xiaoshu Wang wrote:
>
>> 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.
>
> That part I understand (and agree that the wording change is an 
> improvement.) The part I am still worried about is the claim that a 
> 303 redirect necessarily means that the server *does not have* a 
> representation. I think this is (a) wrong, in that such a 
> representation may exist, but the server may choose not to deliver it 
> for some reason on this occasion, and (b) needlessly strong, since 
> nothing hinges on the existence or otherwise of this representation. 
> The http-range-14 decision does not depend on this being the intended 
> meaning of a 303 redirect: it requires only that a 200-level 
> representation for the requesting URI is *not* delivered, even 
> indirectly (as would be the case with a 301 or 307, for example). And 
> since this is all that is required, it seems like good practice to not 
> say anything more, on the grounds that whatever else is said will 
> likely come back to bite you later.
>
> For example, here is a possible scenario. I have an OWL ontology all 
> about breeding horses, and it uses hash-coded URIrefs throughout to 
> denote breeds of horse, like http://ex.thehorseplace.com/foo#arabian. 
> I also want to use the bare URI http://ex.thehorseplace.com/baz to 
> denote my company (not my website), so I need to do a 303 redirect 
> when this URI comes along. All this is done by my one web server, 
> however. So this entity which handles all this has access to a 
> representation of itself, which it will 200-deliver when given the URI 
> http://ex.thehorseplace.com/foo, but when given the URI 
> http://ex.thehorseplace.com/baz it will ignore this representation and 
> perform a 303 redirect to a document about my company. Now, I could 
> say that there are two resources here, each with its own URI, but that 
> wouldnt in fact reflect the reality of how my website is constructed. 
> What there is, is one entity which has two URIs and which responds 
> differently to them. In one case, it **has** a representation but 
> **chooses** not to deliver it, in order to comply with http-range-14.
>
> So, I would suggest changing the wording to something like:
>
> A 303 response to a GET request indicates that the server will not 
> deliver a transferable representation of ...
Yes, I think this wording is good.

Xiaoshu

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