W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

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

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 9 Jan 2008 17:39:16 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Roy T. Fielding" <fielding@gbiv.com>
Message-Id: <1B2DDA92-EFDA-4166-970B-FD2DB5829A17@mnot.net>
To: Jamie Lokier <jamie@shareable.org>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC