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

Henrik mentioned a counterproposal in passing:

> The "requested variant" is pretty clear. The variant returned had the
> request been a GET request, or in case of the ETag returned by PUT a  
> GET
> request immediately after completion of the PUT.


I've seen at least one other person agree (assumedly after appropriate  
wordsmithing). Roy, thoughts?


On 28/12/2007, at 9:49 AM, Jamie Lokier wrote:

>
> Mark Nottingham wrote:
>>> variant
>>>    The ultimate target resource of a request after indirections
>>>    caused by content negotiation (varying by request fields) and
>>>    method association (e.g., PROPFIND) have been taken into account.
>>>    Some variant resources may also be identified directly by their
>>>    own URI, which may be indicated by a Content-Location in the
>>>    response.
>
> When a variant is identified by its own URI indicated by
> Content-Location, and keeping in mind that target of a request may
> depend on request method and other things, _how_ is that
> Content-Location URI supposed to be used?
>
> Does it mean GET should be used with the Content-Location URI to fetch
> that specific variant, while other methods cannot be depended upon to
> access the specific variant (particularly if the specific variant was
> originally selected dependent on request method)?  If so, the unique
> role of GET on Content-Location URIs should be made clear.
>
> -- Jamie
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 9 January 2008 06:39:29 UTC