toddmgreer
commented
1 year ago It seems to me that the following are all reasonable behaviors when a cache has a fresh response with an etag that doesn't match the request's If-Match field:
- Ignore If-Match, and serve the cached response
- Proxy the request to the origin
- Serve a 412
- Validate the cached response, then serve a 412 or 200 as appropriate
1 and 2 are clearly compliant, but are 3 and 4 compliant?
Can you clarify what RFC9110 requires a caching intermediary to do (or not do) with a GET request with "If-Match"?
RFC9110 13.1.1 If-Match says that "A cache or intermediary MAY ignore If-Match", which implies that they MAY evaluate If-Match. However, the procedure in 13.2.2. Precedence of Preconditions doesn't allow a recipient cache to honor If-Match. Also, Handling a Received Validation Request says that "the If-Match and If-Unmodified-Since conditional header fields are not applicable to a cache". It also says that "A cache MUST NOT evaluate conditional header fields that only apply to an origin server, occur in a request with semantics that cannot be satisfied with a cached response, or", and If-Match seems to match that check.
Further if a cache chooses to honor If-Match, it's unclear what it should do if it has a fresh response with a different etag. It seems like it should always consult the origin, but in many cases (when the cache is intended to shield origins from load), that's really not what the origin's administrator wants--they want the cache to respond as much as possible.
I think this needs to be corrected in RFC9110, but I'm not sure what the actual intent was.