Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If-Match and caching intermediaries #1111

Open
toddmgreer opened this issue Oct 30, 2023 · 2 comments
Open

If-Match and caching intermediaries #1111

toddmgreer opened this issue Oct 30, 2023 · 2 comments
Labels

Comments

@toddmgreer
Copy link

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.

@toddmgreer
Copy link
Author

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:

  1. Ignore If-Match, and serve the cached response
  2. Proxy the request to the origin
  3. Serve a 412
  4. Validate the cached response, then serve a 412 or 200 as appropriate

1 and 2 are clearly compliant, but are 3 and 4 compliant?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants
@reschke @toddmgreer and others