Re: Review of new HTTPbis text for 303 See Other

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

Received on Wednesday, 8 July 2009 10:19:33 UTC