Can a user agent set a maximum age greater than zero in a request?

Question

I have doubts about max-age behavior after reading Http Cache rfc .

Scenario:

User agent

 GET /foo 

Origin server response header

 cache-control: max-age=120 

The server tells the user agent that the requested resource should be checked after 2 minutes.

After 1 minute and a few seconds, the user agent performs another request, specifying max-age for 1 minute:

User agent

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

From what I understand, this request should bypass the user's cache.
Why?
Although Origin Server told the client that the resource should be cached for 2 minutes, the user agent needs a resource that is no more than 1 minute ( max-age = 60 ).
After 1 minute and a few seconds from the first GET this resource is invalid (from the point of view of the user agent), and the request should go directly to the source server (or any other cache levels).

I'm right? Is it possible to specify from User Agent a max-age greater than zero? Is it supported / respected by regular browsers?

Where I work, we have our own .NET caching mechanism, which works like this: clients can specify max-age when they need a resource from the cache, which is "AT MYSELF" X seconds.

Answer 1

There is no doubt about it. RFC7234 Section 5.2.1.1 includes an example max-age=5 , which, of course, is greater than zero. The definition is also clear (my attention):

The Maximum Age Directive indicates that the client does not want to accept a response whose age exceeds the specified number of seconds .

The “indicated number of seconds” may be any non-negative integer (defined in Section 1.2.1 ). So the answer is a definite yes.

In addition, the above definition also explains the behavior of the cache in your scenario. But before I get to this, I have to fix the following:

The server tells the user agent that the requested resource should be checked after 2 minutes.

Wrong.

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

The response directive "max-age" indicates that the answer is considered obsolete after its age exceeds the specified number of seconds.

As you can see, recertification requirements are not required. If requests for the same resource are not up to 10 minutes later, re-certification will not continue until 10 minutes.

In addition, from Section 5.2 (emphasis added):

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

It just caches, not the 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 simply cached. Remember, just because you received it does not mean that it is for you.

For the rest of your scenario, your assessment is correct. I will bring it here:

After 1 minute and a few seconds, the user agent performs another request, specifying max-age 1 minute:

...

From what I understand, this request should bypass the user's 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 the saved response is, say, 65 seconds, it cannot be used to satisfy the request using the max-age=60 directive. Thus, the cache simply obeys the directive it receives.

In fact, any standards-compliant HTTP cache, whether integrated into a browser or a separate one, must obey the directive it receives, as described in Section 5.2 (top notch from the source, not mine):

The cache MUST comply with the requirements of the Cache-Control directives defined in this section.

Based on what you described, the custom caching mechanism that you have at work seems to be up to standard. So, my additions to the developers, especially if by "custom" you mean "developed in the house."

Answer 2

From RFC2616 max-age

  When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency. However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client request, using the strong comparison function. If the client validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response. If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age. 

From the last lines of the RFC:

If the request includes the no-cache directive, it MUST NOT include the minimum, maximum, or maximum age.

From 13.2.6 Section "Separation of ambiguous answers"

 When a client tries to revalidate a cache entry, and the response it receives contains a Date header that appears to be older than the one for the existing entry, then the client SHOULD repeat the request unconditionally, and include Cache-Control: max-age=0 to force any intermediate caches to validate their copies directly with the origin server, or Cache-Control: no-cache to force any intermediate caches to obtain a new copy from the origin server. If the Date values are equal, then the client MAY use either response (or MAY, if it is being extremely prudent, request a new response). Servers MUST NOT depend on clients being able to choose deterministically between responses generated during the same second, if their expiration times overlap. 

I understand that on the client side (user agent) max-age=0 can be used as a mechanism for using the latest saved version, unlike no-cache , which will restore the resource.

 curl -I -H 'Cache-Control: no-cache' http://example.com 

Therefore, if you use max-age with a value greater than zero instead, it should use the saved version corresponding to the difference between the received date in the headers, the value defined in max-age .

Not sure. If I love it, but I don’t know.

In addition to a similar question: What is the difference between Cache-Control: max-age = 0 and no-cache?