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

Mark Nottingham wrote:
> 
> I've only seen a few responses to one aspect of this, so I'll restate as 
> a set of proposals.
> 
> ...
> 
> 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."

+1

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

+1

>> 10.2.5 (204 No Content):
>>> The server has fulfilled the request but does not need to return an 
>>> entity-body, and might want to return updated metainformation. The 
>>> response MAY include new or updated metainformation in the form of 
>>> entity-headers, which if present SHOULD be associated with the 
>>> requested variant.
>>
>> This makes internal sense; see comments about adjusting the definition 
>> above.
> 
> PROPOSAL: s/requested variant/selected representation/

+1

>> 10.2.7 (206 Partial Content) and 10.3.5 (304 Not Modified):
>>> The response MUST include the following header fields:
>> [...]
>>> - Expires, Cache-Control, and/or Vary, if the field-value might 
>>> differ from that sent in any previous response for the same variant
>>
>> Here's where IMO a distinct term does add some value; if we said 
>> 'representation', it would be tied to a particular entity, which 
>> doesn't make much sense. OTOH 'variant' doesn't clarify things 
>> greatly, as it's currently defined. "...any previous instance of the 
>> selected representation'?
> 
> PROPOSAL: s/response for the same variant/instance of the selected 
> representation/

+1

>> 14.14 (Content-Location)
>>> The Content-Location entity-header field MAY be used to supply the 
>>> resource location for the entity enclosed in the message when that 
>>> entity is accessible from a location separate from the requested 
>>> resource's URI. A server SHOULD provide a Content-Location for the 
>>> variant corresponding to the response entity; especially in the case 
>>> where a resource has multiple entities associated with it, and those 
>>> entities actually have separate locations by which they might be 
>>> individually accessed, the server SHOULD provide a Content-Location 
>>> for the particular variant which is returned.
>>
>> This is where things get fairly muddy. Variant is currently defined as 
>> a kind of representation, but here all of the sudden it's treated as a 
>> resource and given a URI. The first instance could probably be 
>> replaced by just 'resource', or just drop 'for the variant' entirely; 
>> in the second, 'representation' would probably suffice.
> 
> PROPOSAL: s/for the variant//; s/the particular variant/the particular 
> representation/

The original text already is kind of confusing to me. First it makes a 
SHOULD level requirement; then it talks about a special case and points 
out what seems to be the same SHOULD level requirement. Maybe we need to 
rewrite the whole paragraph?

>> 14.19 (ETag)
>>> The ETag response-header field provides the current value of the 
>>> entity tag for the requested variant.
>>
>> Makes sense here, but 'requested/selected representation' would do 
>> just fine.
> 
> PROPOSAL: s/requested variant/selected representation/

+1

>> 14.25 (If-Modified-Since)
>>> The If-Modified-Since request-header field is used with a method to 
>>> make it conditional: if the requested variant has not been modified 
>>> since the time specified in this field, an entity will not be 
>>> returned from the server [...]
>>> A GET method with an If-Modified-Since header and no Range header 
>>> requests that the identified entity be transferred only if it has 
>>> been modified since the date given by the If-Modified-Since header. 
>>> The algorithm for determining this includes the following cases: a) 
>>> If the request would normally result in anything other than a 200 
>>> (OK) status, or if the passed If-Modified-Since date is invalid, the 
>>> response is exactly the same as for a normal GET. A date which is 
>>> later than the server's current time is invalid. b) If the variant 
>>> has been modified since the If-Modified-Since date, the response is 
>>> exactly the same as for a normal GET. c) If the variant has not been 
>>> modified since a valid If- Modified-Since date, the server SHOULD 
>>> return a 304 (Not Modified) response.
>>
>> 14.28 (If-Unmodified-Since)
>>> If the requested variant has been modified since the specified time, 
>>> the server MUST NOT perform the requested operation, and MUST return 
>>> a 412 (Precondition Failed).
>>
>> 14.29 (Last-Modified)
>>> The Last-Modified entity-header field indicates the date and time at 
>>> which the origin server believes the variant was last modified.
>> Interestingly, Last-Modified validation is defined in terms of 
>> 'requested variant', whereas ETag validation (If-Match, If-None-Match) 
>> seem to go out of their way to say that *any* entity that meets the 
>> conditional can be returned, and never mind the selecting headers. I'd 
>> be interested in hearing if any implementations actually do that, and 
>> unless some are found, I'd suggest we need to tighten up how ETag 
>> validation is defined..

Sounds right to me.

> PROPOSAL: s/requested variant/selected representation/g; 
> s/variant/selected representation/g

+1

> And, add an issue about the implied divergence in the ETag and LM 
> validation models.

+1

BR, Julian

Received on Wednesday, 13 February 2008 13:35:31 UTC