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

I think the best way to characterise the situation currently is that HTTP doesn't define any requirements for If-Match on non-origin servers; the only requirements in 7232 Section 3.1 apply to origin servers.

AFAIK current intermediaries ignore If-Match, so if you wanted to define some guidelines here, they'd need to be completely optional. E.g., "An intermediary MAY process If-Match based upon the contents of its cache, replying with 4xx when..." (note that that's just rapid hand-waving, not suggested spec text).

If we did that, we'd have a header whose handling by origin servers was mandatory for some methods, and handling by intermediary servers was optional for other methods. Not sure how much that would confuse people, but properly spec'd, it'd probably be OK.

We'd also have to have a discussion about whether 412 was the right status code.

Roy, any thoughts?

Tom, can you say any more about your use case?

Cheers,





> On 18 Feb 2017, at 9:06 am, Tom Bergan <tombergan@chromium.org> wrote:
> 
> 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.

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

Received on Sunday, 26 February 2017 23:50:38 UTC