Re: Review of new HTTPbis text for 303 See Other

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.

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

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

> ...

BR, Julian

Received on Wednesday, 1 July 2009 04:56:57 UTC