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

Re: i107

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 28 Jul 2008 15:34:15 +0100
Cc: Brian Smith <brian@briansmith.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <75A97989-4657-4B29-9B5D-8037429F8F42@mnot.net>
To: Henrik Nordstrom <henrik@henriknordstrom.net>

Julian and I were just discussing this (alas, not yet over a Guinness).

I think the right thing to do here is to describe both variant  
selection (p3, section 5.1, p6, 16.5) and validator comparison (p4  
section 5) in terms of set theory (at least informally), so that the  
set of representations available for a given request is the  
intersection of those selected by negotiation and those requested  
conditionally.

Make sense?


On 13/03/2008, at 10:55 PM, Henrik Nordstrom wrote:

>
>
> On Wed, 2008-02-27 at 21:53 -0800, Brian Smith wrote:
>>> 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.
>
> If-None-Match is pretty clearly defined to apply to "the selected
> representation" only.
>
>   If any of the entity tags match the entity tag of the entity that
>   would have been returned in the response to a similar GET request
>   (without the If-None-Match header) on that resource, or if "*" is
> [...]
>
>   The meaning of "If-None-Match: *" is that the method MUST NOT be
>   performed if the representation selected by the origin server (or by
>   a cache, possibly using the Vary mechanism, see section 14.44)
>
>
> Same thing for If-Match (exact same wording, only negated to match the
> condition).
>
> Regards
> Henrik
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Monday, 28 July 2008 14:34:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:53 GMT