I recently went through this article. It says that not only response, the requests can also include cache-control
options.
Though I understood, it can be utilized by server responses meaningfully, I don't clearly understand why they are needed in requests. Unfortunately I could find nothing on internet which got answers to my problem.
Any one has an idea?
Without the cache control header the browser requests the resource every time it loads a new(?) page.
Cache-control is an important way by which developers can dictate how resources will be cached when a user browses the internet. Without cache-control, the browser caching and the resulting experience for the user will be sub-optimal.
Expiration is the caching mechanism by which a client can entirely avoid making requests to the origin server. When the origin server specifies an explicit expiration time in the resource, a cache can check that expiration time and respond accordingly without having to contact the server first.
The HTTP cache stores a response associated with a request and reuses the stored response for subsequent requests. There are several advantages to reusability. First, since there is no need to deliver the request to the origin server, then the closer the client and cache are, the faster the response will be.
HTTP/1.1 cache and the associated headers that control cache behavior are defined in the RFC 7234. Caching is an entirely optional feature of HTTP though.
The Cache-Control
header is used to specify directives for caches along the request/response chain. Such cache directives are
unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.
Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use both token and quoted-string syntax. For the directives defined below that define arguments, recipients ought to accept both forms, even if one is documented to be preferred. For any directive not defined by this specification, a recipient MUST accept both forms.
Cache-Control = 1#cache-directive cache-directive = token [ "=" ( token / quoted-string ) ]
Find below the directives that can be used in the request for the Cache-Control
header:
5.2.1.1. max-age
[...] 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. [...]This directive uses the token form of the argument syntax: e.g.,
max-age=5
notmax-age="5"
. [...]
5.2.1.2. max-stale
[...] The
max-stale
request directive indicates that the client is willing to accept a response that has exceeded its freshness lifetime. [...]This directive uses the token form of the argument syntax: e.g.,
max-stale=10
notmax-stale="10"
. [...]
5.2.1.3. min-fresh
[...] The
min-fresh
request directive indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. [...]This directive uses the token form of the argument syntax: e.g.,
min-fresh=20
notmin-fresh="20"
. [...]
5.2.1.4. no-cache
The
no-cache
request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server.
5.2.1.5. no-store
The
no-store
request directive indicates that a cache MUST NOT store any part of either this request or any response to it. [...]
5.2.1.6. no-transform
The
no-transform
request directive indicates that an intermediary (whether or not it implements a cache) MUST NOT transform the payload [...].
5.2.1.7. only-if-cached
The
only-if-cached
request directive indicates that the client only wishes to obtain a stored response. [...]
In a similar way, RFC 7234 also defines the directives that can be used in the response for the Cache-Control
header.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With