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

RFC7234: First-hand responses and age #23

Closed
mnot opened this issue Apr 21, 2017 · 2 comments
Closed

RFC7234: First-hand responses and age #23

mnot opened this issue Apr 21, 2017 · 2 comments

Comments

@mnot
Copy link
Member

mnot commented Apr 21, 2017

From http://www.w3.org/mid/57351E03.1090103@measurement-factory.com:

Imagine a cache that has a stored response A with a Date value X. The
cache sends a conditional request to validate that cached response. The
cache receives a 200 OK response B with a Date value of Y.

If X <= Y, then the situation is clear -- A is stale and the cache
should use B.

What if X > Y? In other words, what if the cache receives a 200 OK
response B that appears to be older (i.e., even more stale) than the
response A the cache is trying to validate? Should the cache trust the
sender's staleness decision or its own date comparison logic?

  • RFC 7234 section 4 says "a cache MUST use the most recent response (as
    determined by the Date header field)". That means A wins.

  • RFC 7234 section 4.3.3 says "the cache MUST use the full response [it
    just received]". That means B wins.

  • RFC 2616 section 13.2.5 says "If a client performing a retrieval
    receives a non-first-hand response for a request that was already fresh
    in its own cache, and the Date header in its existing cache entry is
    newer than the Date on the new response, then the client MAY ignore the
    response". That means A wins if A was fresh and B came from a cache.

If I have to guess, I would use B if it does not have an Age header,
boldly assuming that it is a first-hand response. Otherwise, use A. With
more time/effort, revalidating with max-age=0 would be a good option
(but it may result in the same conundrum).

Is this a gray area, or did I miss a specific HTTPbis rule that resolves
this conflict? Was the quoted RFC 2616 MAY replaced with something
equally specific? If this is a gray area, what do you recommend?

@mnot mnot added the caching label Jun 20, 2017
@mnot
Copy link
Member Author

mnot commented Jun 29, 2018

The first bullet point in full is:

  • When more than one suitable response is stored, a cache MUST use the most recent response (as determined by the Date header field).

This is a bit different; it only takes effect when there are multiple stored responses, and implies that the MUST applies to those stored responses, not the one from the network. There's a bit of related background here.

So right now, it's "B wins."

At first blush, I tend to agree with Alex's guess; in particular, if an upstream cache serves something stale (e.g., due to SwR) and you have something that's newer in cache, intuitively you should use the newer one.

However, what if multiple entity-tags had been sent in If-None-Match and the server is explicitly selecting one? AFAIK that isn't common behaviour, but it does seem allowable by the current specs.

I think the possible resolutions here are to a) close with no action, or b) allow a fresher stored response to be used.

@mnot mnot added the discuss label Jul 4, 2018
@mnot
Copy link
Member Author

mnot commented Oct 9, 2018

I'm leaning towards closing this with no action, or at most clarifying "When more than one suitable response is stored, a cache MUST use the most recent response" to read "When more than one suitable response is stored, a cache MUST use the most recent one."

Any thoughts?

@mnot mnot added has-proposal and removed discuss labels Oct 9, 2018
@mnot mnot closed this as completed in 5318e5f Nov 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant