Re: Review of new HTTPbis text for 303 See Other

On Jul 8, 2009, at 5:18 AM, Julian Reschke wrote:

> Hi Jonathan,
>
> > ...
>>> Could you please provide an example for a resource like that? My
>>> understanding of the 303/information resource issue always was  
>>> that if the
>>> resource can be represented with a bag of bits then it *is* an  
>>> information
>>> resource.
>> The TAG resolution, FWIW, says that if the response is a 303, the
>> resource can be any kind of resource - information or non- 
>> information.
>
> Indeed. (<http://www.w3.org/2001/tag/issues.html#httpRange-14>)
>
>> My application is creating a large number of stable URIs (PURLs, in
>> effect) for what could be considered information resources, AND  
>> adding
>> metadata in the process, with the metadata reachable via 303. (The
>> data would be found in some other way, not via 200.) This is because
>> the metadata is deemed more important than the data.
>> Now I have three ways out. One is for me to tell myself that "the
>> requested resource does not have a representation of its own that can
>> be transferred by the server over HTTP", which of course is  
>> untestable
>> and so I doubt anyone would call me on it. Another is to ignore your
>> 303 advice, as it will only have SHOULD status and not MUST status.
>> Yes another is to use LRDD to provide access to the metadata, but  
>> LRDD
>> is not likely to be ready before HTTPbis, and it's not obvious (yet)
>> that it will serve my purposes.
>
> Well, it's not "my" advice, but the text this working group  
> previously came up with. (I think Roy proposed it).
>
> My understanding is that if you apply GET to a resource for which  
> you *do* have a representation, than you should respond with a 200  
> status, and return it.
>
>> I can reverse the question and ask *you*: Tell me what kind of
>> resource "does not have a representation of its own that can be
>> transferred by the server over HTTP"? And what is an example of a
>
> Those that Web-Arch calls "non-information" resources. Keep in mind  
> that this specific text has been put it to address httprange; it  
> wasn't present in RFC2616.
>
>> representation that cannot be transferred over HTTP? You have entered
>> one of the nastiest and most pointless debates around, that of the
>> boundary between information resources and other resources, and I
>> don't recommend going there - it's an ontological quagmire that has  
>> no
>> place in HTTPbis.
>
> I didn't enter it. Actually, the spec tries to avoid it:
>
> "A 303 response to a GET request indicates that the requested  
> resource does not have a representation of its own that can be  
> transferred by the server over HTTP.

That just seems plain false. A 303 does not indicate that something  
does not exist. It simply indicates that the server, for reasons which  
may be entirely opaque and nobody is under any obligation to explain,  
has decided to redirect the query elsewhere. The http-range-14  
decision adds to this that, under these 303 circumstances, the  
original URI **may** be intended to denote something which has no  
representation appropriate to a 200 level response, but this is not  
actually implied by the 303 response itself, only permitted. The only  
actual constraint in all this is that if the URI elicits a 200 level  
response, then the payload of that response is a representation of the  
resource that the URI is understood to denote. And this does not  
mention 303 redirection.

Pat Hayes

> The Location URI indicates a resource that is descriptive of the  
> requested resource such that the follow-on representation may be  
> useful without implying that it adequately represents the previously  
> requested resource. Note that answers to the questions of what can  
> be represented, what representations are adequate, and what might be  
> a useful description are outside the scope of HTTP and thus entirely  
> determined by the resource owner(s)."
>
>> Better to just say that GET/303 may be used any time the server does
>> not choose, for whatever reason, to respond with a representation,  
>> but
>> rather with the location of a description of the resource. This is
>> easy to specify and describe and is compatible with the TAG's  
>> previous
>> advice.
>
> ...but it seems to be a change to what HTTP said before; from HTTP's  
> point of view it's strange to talk about resources that do have  
> representations, but do not return them upon GET.
>
>
>>>> ...
>>>>
>>>> I recommend changing this to something weaselly like
>>>>
>>>>  A 303 response to a GET request *may indicate* that the requested
>>>> resource
>>>>  does not have a representation of its own that can be  
>>>> transferred by ...
>>>> ...
>>> Assuming we did want to change it, it would still to be phrased in  
>>> a way
>>> that explains what 303 means, not what it "may" mean...
>> See above. I don't think much meaning has to be given beyond that you
>> get the location of a description. You can leave the 200/303 choice  
>> up
>> to the server, just as a choice between a 300 and a 200 is up to the
>> server. The server just decided.
>
> I understand that; but the language defining the status codes needs  
> to be phrased so that it's clear what it means, not what it "may"  
> mean.
>
>>>> 2. The last sentence is also incorrect - to say that these  
>>>> decisions
>>>> are up to the resource's owner is also too strong a commitment. For
>>>> example, if I create a URI meant to "identify" my neighbor's car,  
>>>> it
>>>> is not necessarily up to my neighbor to determine what a useful
>>>> description of it is.
>>> From HTTP's point of view, the owner of the URI is the owner of the
>>> resource. It just doesn't care about the case where you use an  
>>> HTTP URI to
>>> identify somebody's car.
>> But you are the one who raises the question. If you mean resource
>> owner in some narrow technical sense, instead of resource owner in,
>> say, a legal sense (e.g. copyright), you need to be clear. It wasn't
>> clear to me, and I don't think it's only because I'm steeped in a
>> world view that makes a clear separation between URI and resource
>> (e.g. the possibility that many URIs with different URI owners might
>> all identify the same resource).
>> ...
>
> Understood. How do others feel about HTTP's use of the term  
> "resource owner"?
>
> 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

Received on Wednesday, 8 July 2009 20:38:11 UTC