Retrofit: server returns both ETag and Cache-Control: max-age=60. Shouldn't the cache be used if request < 60s?

Question

I am using Retrofit, configured to used OkHttp with a cache. I am calling this api: https://api.github.com/users/bod/repos which returns both an Etag and a Cache-Control: public, max-age=60, s-maxage=60 headers.

I make two requests, in less than 60 seconds, so I was expecting the second one to not perform any network at all and to use the cache, per the Cache-Control directive. But that's not what I see.

I am guessing this is because the Etag directive takes precedence?

Is that correct / normal / expected behavior?

Answer 1

RFC2068 Hypertext Transfer Protocol -- HTTP/1.1 published in 1997 details both ETag and Cache-Control Headers. Later documents, RFC2616 and RFC7232 both expand on the ETag header and how it can be used with If-None-Match.

RFC2616, 13.3 Validation Model contains the answer to your question:

When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call this "validating" the cache entry.

It then goes on to list validation models, including Entity Tag (ETag) Cache validators along with Last-Modified dates. A stale cache entry is one where the maxage or other expiry mechanism has occurred for that resource.

So the behavior of your system is unexpected. It may be worth testing content with and without the ETag header to verify if the local cache is working at all.