Subject: WGLC #354 - ETags & conditional requests

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Jun 2012 13:47:46 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/354>; related text is at <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html#header.if-match>

Usually, this isn't a problem, because If-Match is only used with methods that to be written through to the origin server. E.g., when you PUT or POST something. 

However, we shouldn't count on that.

One way to address this would be to target the requirements at "origin server" rather than "server"; i.e. to say that we don't expect intermediaries to process If-Match.

Thoughts?

On 24/04/2012, at 3:47 AM, Ben Niven-Jenkins wrote:

> Hi,
> 
> Apologies that this mail misses the WG LC deadline, in Velocix we're reviewing all the HTTPBIS documents but we're a little behind, hence the late comments, sorry. (we're still reviewing so might have more comments as we work through the documents)
> 
> On page 14 of P4 it states:
> 
>  If none of the entity-tags match, or if "*" is given and no current
>  representation exists, the server MUST NOT perform the requested
>  method.  Instead, the server MUST respond with the 412 (Precondition
>  Failed) status code.
> 
> This appears to apply to intermediates, but If-Match has a problem
> here that If-Unmodified-Since does not. If a proxy has a cached
> entity which has a newer Last-Modified timestamp it *knows* that
> the conditional has failed and can generate the required
> 412 Precondition Failed response itself. Otherwise it can satisfy
> the request from cache. Or relay if there is no current cached
> version.
> 
> But because multiple responses with different ETags may exist then a cache receiving If-Match with one etag, when it has a different etag cached, can not know for sure that the request etag does not exist. If it were to respond with a 412 status it would effectively be preventing the use of that conditional.
> 
> It would appear that the only two options available to an intermediate are to satisfy the request in the case of a known match, and relay upstream in all other cases (which would be in conflict with the spec as quoted above).
> 
> Thanks
> Ben
> 
> 

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

---

From: Zhong Yu <[email-masked]>
Date: Thu, 21 Jun 2012 10:43:16 -0500

A valid use case for GET + If-Match may be a range request.

If the intermediary has a cached representation with matching tag,
which it has reason to believe would be the "selected representation"
from the original server, the intermediary may safely do the shortcut.
Otherwise the request has to be forwarded to the original server.

Zhong Yu

---

From: John Sullivan <[email-masked]>
Date: Thu, 21 Jun 2012 16:51:03 +0100

> Otherwise the request has to be forwarded to the original server.

Yes. It was only the conditional failure case that I was worried
about, where the usefulness of this header is severely compromised
by an intermediate generating 412s.

>>> It would appear that the only two options available to an intermediate are to satisfy the request in the case of a known match, and relay upstream in all other cases (which would be in conflict w…

John
--

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jun 2012 10:35:17 +1000

Of course, thanks; I always forget about the Range cases.

How about:

"""
If any of the entity-tags listed in the If-Match field value match (as per Section 2.3.2) the entity-tag of the selected representation for the target resource, or if "*" is given and any current representation exists for the target resource, then the server may perform the request method as if the If-Match header field was not present.

Origin servers must not perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead, they must respond with the 412 (Precondition Failed) status code.

Proxy servers using a cached response as the selected representation must not perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead, they must forward the request towards the origin server.
"""

---

From: John Sullivan <[email-masked]>
Date: Fri, 22 Jun 2012 12:45:28 +0100

> Proxy servers using a cached response as the selected representation must not perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists;…

That sounds good to me - just a minor question about the wording:

    If any of the entity-tags listed in the If-Match field value match
    (as per Section 2.3.2) the entity-tag of the selected representation
    for the target resource

That makes it sound like, in cases where the server has multiple
representations available, it will first choose one, *then* compare
with If-Match. (So if several equivalent versions are available and
If-Match contains one ETag, and the server chooses the "wrong" one
in step 1, it will always fail to match in step 2.) I just wondered
whether the opposite way is specifically excluded: search the available
versions for one matching an ETag present in If-Match, which will always
succeed if a matching representation is present.

John
--

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 23 Jun 2012 12:09:28 +1000

Yes. Note that "selected representation" is defined earlier:

> We use the term "selected representation" to refer to the current representation of the target resource that would have been selected in a successful response if the same request had used the method GET and had excluded all of the conditional request header fields. The conditional request preconditions are evaluated by comparing the values provided in the request header fields to the current metadata for the selected representation.

Now, a cache could have multiple representations of a resource stored, but again the selection algorithm again only has one output; see <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#caching.negotiated.responses>.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jun 2012 12:03:51 +1000

Haven't heard any objection, so I've assigned for incorporation in -20.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Jun 2012 17:58:40 +0200

On 2012-06-27 04:03, Mark Nottingham wrote:
> ...

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1696>

Best regards, Julian