Re: Review of new HTTPbis text for 303 See Other

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

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

(Just to clarify for the record, I am not intending here to quarrel  
with http-range-14, only with the wording being used to express it.)

Pat

> Xiaoshu
>
>

------------------------------------------------------------
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, 9 July 2009 17:14:11 UTC