W3C home > Mailing lists > Public > www-tag@w3.org > July 2009

Re: Review of new HTTPbis text for 303 See Other

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 7 Jul 2009 16:44:33 -0400
Message-ID: <760bcb2a0907071344q1a5faf56g19b36c3efd661533@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
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.

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.

>> ...
>>
>> 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
>
Received on Tuesday, 7 July 2009 20:45:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:14 GMT