Re: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

On Feb 14, 2008, at 5:25 AM, Julian Reschke wrote:

> Adrien de Croy wrote:
>> Quick question (hopefully) - what's the difference between  
>> "representation" in this case and "entity"?  I feel I'm missing  
>> something.
>> ...
>
> OK, let's try.
>
> A representation:
>
> "An entity included with a response that is subject to content  
> negotiation, as described in Section 12. There may exist multiple  
> representations associated with a particular response status." --  
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.1.3>

Yikes, no thanks.

> An entity:
>
> "The information transferred as the payload of a request or  
> response. An entity consists of metainformation in the form of  
> entity-header fields and content in the form of an entity-body, as  
> described in Section 7."

That is a representation.  I was hoping to replace entity at some  
point for
that reason.  The payload is always a representation of *some*  
resource.  The
status code tells us which resource it is, and Content-Location tells  
us its
most specific URI.

Getting back to Mark's proposal regarding 'requested variant'... I think
that is headed in the right direction but will need some tweaks.

    PROPOSAL: Remove 'requested variant' from terminology and define
    'selected representation' as (roughly): "The representation that  
would be
    returned by the server if the request method were GET, taking into
    consideration selecting headers, as specified by the Vary  
header's payload."

I would say that it is: "The representation that would be returned by  
the
origin server if the request method were GET and the response status  
200."

Note that Vary is one of those fields that is overspecified in 2616.
Vary is supposed to be instructions to any downstream caches, not a
limitation on origin server implementation.  A server is fully within  
its
rights to vary its representations however it likes without telling
the downstream recipients -- it only needs to tell the client what it
requires of any downstream cache keys (i.e., the interface requirement).

    PROPOSAL: Define the response to PUT, POST, DELETE, and OPTIONS  
to carry
    a "status message," not a representation, UNLESS a Content- 
Location is
    present OR (in the case of POST) there is explicit freshness  
information.
    As such, ETags, etc. do not apply to them.

    (This is a straw-man that I expect this to be controversial; just  
trying
    to get things going...)

Er, I don't think so.  It really isn't that hard to distinguish between
a representation of the requested resource and a representation included
as payload within a message, even when we take into consideration the
206 partial responses (a representation of a set of ranges of the  
selected
representation).  Note that "status messages" are also subject to
negotiation.

    PROPOSAL:
    A 201 response MAY contain an ETag response header field  
indicating the
    current value of the newly created resource's selected  
representation ETag
    (i.e., the ETag that would be returned if the same selecting  
headers had
    been sent in a GET request to it).

By "newly created resource" and "to it", I assume you mean the resource
identified by the Location header field for POST and by the requested  
URI
for PUT.  Better to just say that.

The other spots that requested variant is used are all within  
sections that
need a general rewrite.

....Roy

Received on Thursday, 14 February 2008 18:50:09 UTC