Re: Review of new HTTPbis text for 303 See Other

On Tue, 7 Jul 2009, Jonathan Rees wrote:

> Comments inline below.
>
> On Wed, Jul 1, 2009 at 12:56 AM, Julian Reschke<julian.reschke@gmx.de> wrote:
>> Jonathan Rees wrote:
>>>
>>> Quoting from
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#page-24
>>> :
>>>
>>>   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.  ...  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).
>>>
>>> 1. I think the first sentence makes too strong a commitment. Some
>>> sites are using 303 for resources that *do* have perfectly good
>>> representations that can be transferred by the server over HTTP; they
>>> just don't want to do so because they consider the 303 redirect to a
>>> description of the resource to be more valuable than providing
>>
>> 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.
> 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.

How about qualifying the 303 response (which is something I really don't 
like as a response to a GET, a new code would have been better) using a 
Link: header to specify that the targeted resource is intended to be 
metadata?

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

rfc2616 makes no assumption that it is metadata (hence my proposal above 
to use Link: in this specific case).

>>> ...
>>>
>>> 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.
>
>>> 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).
>
> Best
> Jonathan
>
>>> ...
>>
>> BR, Julian
>>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 8 July 2009 09:50:49 UTC