Re: Review of new HTTPbis text for 303 See Other

On Jul 15, 2009, at 4:38 AM, Julian Reschke wrote:

> Larry Masinter wrote:
>> This conversation is filling my mailbox. Some general
>> observations:
>> ...
> Larry,
> thanks a LOT for this reply.
> My takeaway is that we (the HTTPbis WG) are willing to do minor word  
> smithing to clarify things, but that's it.
> In draft 07, we already replaced "resource owner" by "URI owner", as  
> suggested by Roy.
> In another mail (< 
> >), Roy proposed another change:
>> 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

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


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

Received on Wednesday, 15 July 2009 16:24:19 UTC