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

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:

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).

> 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.



Received on Friday, 17 February 2017 01:21:47 UTC