Subject: RE: i107

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 13 Mar 2008 23:55:47 +0100

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

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 13 Mar 2008 21:09:43 -0700

Henrik Nordstrom wrote:
> If-None-Match is pretty clearly defined to apply to "the 
> selected representation" only.
> 
>    (without the If-None-Match header) on that resource, or if 
>    "*" is [...]

The specification also says: "A client that has one or more entities
previously obtained from the resource can verify that none of those
entities is current by including a list of their associated entity tags
in the If-None-Match header field."

If the purpose is to allow the client to verify that none of the
entities it has are current (conversely, at least one of its
currently-held entities are current), then the server must consider all
entities for the resource, not just the ones that would bet returned by
a similar GET.

Also, the name itself, If-*None*-Match, indicates that it isn't supposed
to be matched against multiple entities, not just against a singular
"selected representation".

>    performed if the representation selected by the origin 
>    server (or by a cache, possibly using the Vary mechanism,
>    see section 14.44)

The specification also says: "As a special case, the value '*' matches
any current entity of the resource." and "...if '*' is given and any
current entity exists for that resource...".

Consider a resource /foo that has a single text/plain representation,
and the following request:

   PUT /foo HTTP/1.1
   If-None-Match: *
   Accept: text/html

If the server would respond with 406 Not Acceptable to a GET with the
same headers, then should it process the PUT? No, because If-None-Match:
* matches any current entity, not just one that would have been returned
by a similar GET request.

Regards,
Brian

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 14 Mar 2008 13:41:35 +0100

> entities for the resource, not just the ones that would bet returned by

Current for that request only.

> "selected representation".

It's a match to a singular selected server representation. Why it's a
list in the request is due to Vary processing, where the client may have
multiple entities cached under the resource URI of which at most one is
the current one for this request.

Example sequence:

GET /object HTTP/1.1
A: a

HTTP/1.0 200 OK
Vary: A
ETag: "one"

GET /object HTTP/1.1
A: b
If-None-Match: "one"

HTTP/1.0 200 OK
Vary: A
ETag: "two"

GET /object HTTP/1.1
A: a2
If-None-Match: "one", "two"

HTTP/1.1 304 Not Modified
Vary: A
ETag: "one"

Regards
Henrik