Can a user agent set a max-age greater than zero in its request?

Question

I have a doubt about max-age behaviour after reading the Http Cache rfc.

Scenario:

User agent

GET /foo

Origin Server Response header

cache-control: max-age=120

Server tells user agent that the resource requested should be revalidated after 2 minutes.

After 1 minute and few seconds, User agent makes another request, specifying a max-age of 1 minute:

User agent

cache-control: max-age=60
GET /foo

From what I understand, this request should bypass the user agent cache.
Why?
Although the Origin Server told the client that the resource should be cached for 2 minutes, User agent needs a resource that is at most 1 minute old (max-age = 60).
After 1 minute and few seconds from the first GET, that resource is not valid (from the User Agent point of view) and a request should go straight to the origin server (Or any other cache layers).

Am I right? Is it possible to specify, from User Agent, a max-age greater than zero? Is it supported/honored by the common browsers?

Where I work, we have a .NET custom caching mechanism that works like this; clients can specify a max-age when they need a resource from the cache that is "AT MOST" X seconds old.

Answer 1

There is no need for any doubt. RFC7234 Section 5.2.1.1 includes an example max-age=5 which is of course greater than zero. The definition is also clear (emphasis mine):

The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds.

"The specified number of seconds" can be any non-negative integer (defined in Section 1.2.1). So the answer is a definite yes.

Additionally, the definition I quoted above also explains the cache behavior in your scenario. But before I get to that, I should correct the following:

Server tells user agent that the resource requested should be revalidated after 2 minutes.

Incorrect.

The max-age=120 directive means that the server tells all caches, not the user agent, that the response must be considered stale after 2 minutes. From Section 5.2.2.8 (emphasis mine):

The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.

As you can see, there is no revalidation requirement. If there are no requests to the same resource until 10 minutes later, there won't be any revalidation until 10 minutes later.

Also, from Section 5.2 (emphasis mine):

The "Cache-Control" header field is used to specify directives for caches along the request/response chain.

Just caches, not user agent.

Each participant in the request/response chain receives the same response with the same Cache-Control header, but the intended recipients of the Cache-Control header are just caches. Remember, just because you receive it, doesn't mean it is for you.

For the rest of your scenario, your assessment is correct. I'll quote it here:

After 1 minute and few seconds, User agent makes another request, specifying a max-age of 1 minute:

...

From what I understand, this request should bypass the user agent cache. Why?

Because at the time of the request, the age of the stored response is more than 60 seconds. It should be obvious that if the age of a stored response is, say, 65 seconds, it cannot be used to satisfy a request with a max-age=60 directive. Thus, the cache simply obeys the directive it receives.

In fact, any standards compliant HTTP cache whether integrated in a browser or separate is required to obey the directive it receives, as stated in Section 5.2 (uppercase emphasis from source, not mine):

A cache MUST obey the requirements of the Cache-Control directives defined in this section.

Based on what you described, the custom caching mechanism you have at work seems to be standards compliant. So, my complements to the developers, particularly if by "custom" you mean "developed in house".