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

Brian Smith wrote:
> To be clear, "representation" always implies "representation of the
> resource," right?

Yes, it should.

> The proposal was that those methods "carry a 'status message,' not a
> representation." That "not a representation" phrase implies that the
> status message cannot be a representation of the resource.

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

So maybe it needs to be rephrased but it certainly does cover the case 
where the response is a representation of the resource.

> The response must always be a status message. The response may also be a
> representation of the resource. The response can never be a
> representation of the resource without also being a status message.

I have no problem with defining it this way.

> Accept-* refer always to the response entity, not to the selected
> representation. (Rather, the Accept-* headers are relevant for selecting
> a representation only when a representation is returned in the response

Disagreed.

> entity.) If I have a DELETE with an Accept-Encoding, that means that I
> want the status message for the request to be encoded a certain way; it
> doesn't mean that I want to delete the representation that has that
> encoding. In order to delete a specific representation of a resource,

It seems to me that questions like these are the ones we want to answer 
in the context of this issue.

Does it make a difference in practice? How do you distinguish between 
request headers that affect the selected representation, and those that 
only affect status messages?

> each representation needs to have its own Content-Location. That is why
> having separate Content-Locations for variants is a SHOULD-level
> requirement in HTTP.

I don't think it is; all I can see is a "SHOULD send Content-Location 
when separate URI exists".

> As another example, let's say I POST an image to a photo book
> application, where the photo book application returns the URL of the
> photo in the Location header of a 201 response, and returns a hyperlink
> to it in the response entity. In my POST, I have "Accept:
> text/plain;q=0.9, text/html;q=1.0" to state I prefer the hyperlink
> (status message) to be in HTML, or plain text as a fallback. However, my
> "Accept" header for the image is not going to be the same; it would be
> "Accept: image/jpg;q=1.0, image/png;q=0.9" if I POSTed a JPEG, and
> "Accept: image/png;q=1.0, image/jpg;q=0.9" if I posted a PNG. (The
> intent here is to always prefer to get back something as close to what I
> posted as possible.)

But the URI you POST to, and the photo URI are distinct; so I don't see 
why that's surprising.

> As another example, I can POST a Japanese document, where the request
> has a "Content-Language: jp". But, I prefer English language status
> messages, so I have "Accept-Language: en". With this proposal, the
> server should return the ETag for an English representation even though
> I am explicitly manipulating a Japanese representation. That is
> counter-intuitive. Again, I set up my client so that it always attempts
> to set its "Accept-*" headers to match the "Content-*" headers of
> whatever was posted, so that I am most likely to retrieve the same
> representation that I posted.

OK, so tying the ETag to Location for 201 would fix this. That may be 
the right thing to do, but I'd still like to leave the definition of 
"selected representation" as simple as possible.

> It would somewhat make sense if the server did its negotiation based on
> the Content-* headers, not Accept-* headers. But, you cannot put
> Content-* headers in a Vary header; Content-* are all entity headers,
> and Vary: can only list request headers. And, this proposal says that
> the server needs to list all the headers it used to select a variant in
> the Vary header.
> 
> It would be better to say that servers should not return an ETag in
> response a response unless there is only one variant ("selectable
> representation"?) for that resource, or unless
> Content-Location=Location, which means the response entity is both the
> status message and the selected representation. Otherwise, the client
> needs to choose which ETag it is interested in by sending a subsequent
> GET or HEAD request with headers that the server can use to select a
> representation.

Nice in theory. In practice, many resources have at least two 
representations (the raw one, and with Content-Encoding: gzip).

>>> Also, the hypothetical GET would have to happen on the Location URI,
> 
>>> not the Request URI, right?
>> That's tricky. I'd prefer this to only be based on Request-URI and 
>> request headers.
> 
> If I POST an image to an AtomPub collection, the ETag in the "201
> Created" response must the one for the entry just created (in the
> Location: header), not the feed document at the Request-URI.

Understood. So minimally in this case, the ETag is not for the selected 
representation.

>>> When I POST with an If-Unmodified-Since or If-Match to an AtomPub 
>>> collection, doesn't that mean "Process this new entry only if the 
>>> collection hasn't been modified"? In other words, If-* headers must 
>>> refer to the resource that is available via a GET at the 
>>> Request-URI--in the case of AtomPub, the collection feed.
>> I think this is what the proposal says.
> 
> My concern is that the "hypothetical GET" that is part of the proposal
> needs to be done against the Location: URI, not the Request URI. In the

Hm, why would it need to be done against anything except the 
Request-URI? Me confused :-)

> proposal, when doing this hypothetical GET, the server would have to
> consider some of the request headers, but it should ignore the If-*
> headers, right? You have to partition request headers into ones that are
> available for consideration when selecting a representation, and which
> ones should/must not be used when selecting a representation.

Which one would not be used for the selection?

BR, Julian

Received on Thursday, 14 February 2008 15:03:04 UTC