Re: Why should caches and intermediaries ignore If-Match?

On Thu, Feb 16, 2017 at 5:21 PM, Alex Rousskov <
rousskov@measurement-factory.com> wrote:

> On 02/15/2017 04:43 PM, Tom Bergan wrote:
>
> > RFC 7232 Section 3.1 says:
> >
> >> The If-Match header field can be ignored by caches and intermediaries
> >> because it is not applicable to a stored response.
> >
> > RFC 7234 Section 4.3.2 says the same thing:
> >
> >> The If-Match ... conditional header fields are not applicable to a
> cache.
> >
> > Why?
>
>
> When rewriting RFC 2616, HTTPbis authors concluded that "caches don't
> have enough information to process methods like If-Match" and decided to
> limit If-Match and If-Unmodified-Since effects to origin servers:
>
>     https://trac.ietf.org/trac/httpbis/ticket/498
>     https://trac.ietf.org/trac/httpbis/ticket/479
>     https://trac.ietf.org/trac/httpbis/changeset/2408
>
> I bet the authors were thinking about classic use cases that deal with
> uncachable resources created and/or updated on the origin server via
> POST/PUT/DELETE methods and missed some more esoteric use cases.
>
> N.B. "can be ignored" is not exactly "MUST ignore" so there is some
> wiggle room for cache optimization here (e.g., mismatching cached
> resources do not have to be DELETEd from a proxy cache, I guess).


Thanks for digging up the history!

> Suppose the client sends a GET request with If-Match: "A". This request
> > is first sent to an HTTP cache. Suppose the requested resource is
> > cached, and suppose the cache ignores the If-Match header as suggested
> > above. If the cache has version "B" cached, not version "A", the cache
> > will return a 2xx with ETag: "B".
>
> Yes, If-Match in HTTPbis is not designed to work [well] with GET methods
> that result in cachable responses.
>
>
> > This behavior is surprising and seems
> > to contradict the following statement from RFC 7232 Section 3.1:
>
> >> [If-Match] can also be used with safe
> >> methods to abort a request if the selected representation does not
> >> match one already stored (or partially stored) from a prior request.
>
> I suspect this text now refers to representations stored on the origin
> server [as the result of prior conditional requests], not
> representations cached by a proxy. Again, the former is probably the
> only intentionally supported use case as far as HTTPbis is concerned.
>
>
> > I am trying to use If-Match for exactly this reason.
>
> Then you have two options:
>
> A) Claim that s/server/origin/g change was wrong and fix HTTPbis RFCs.
> B) Make sure your responses are not cachable.
>
> Given the widespread changes and serious incompatibility with RFC 2616
> that an HTTPbis fix to satisfy your use case would require, I cannot
> recommend (A) unless HTTPbis authors explicitly encourage you to propose
> a fix.
>
>
> > I understand why a cache would not generate 412s. The cache is not
> > authoritative for the resource and 412 implies authority. But, it seems
> > like the cache should never respond with an ETag that is disallowed by
> > If-Match, and if the cache does not have an allowed ETag, then the
> > request should be forwarded to the origin. Does that sound right?
>
> It sounds reasonable to me but it would violate the original RFC 2616
> text and go against the letter (but perhaps not the intent) of the new
> HTTPbis rules.


That would violate the letter of RFC 7232, as you say, but I don't think it
would violate the original RFC 2616 text? RFC 2616 Section 14.24 only
mentions caches once, in relation to If-Match: *, and that mention implies
that caches must handle If-Match:

> RFC 2616 Section 14.24
> The meaning of "If-Match: *" is that the method SHOULD be performed
> if the representation selected by the origin server (or by a cache,
> possibly using the Vary mechanism, see section 14.44) exists, and
> MUST NOT be performed if the representation does not exist.

Mark, Roy, any thoughts?

Given the potential for incompatibility, we're going to look into a
solution that doesn't use If-Match, but it still seems like RFC 7232 should
be updated to explicitly state that either (a) caches should not process
requests with If-Match, or (b) caches may process requests with If-Match,
as suggested above.