HTTP : cache control : headers

Until 2020, I mostly ignored studying IETF protocols in detail. In 2009 I hired a physics graduate off Facebook ads ( client had a limited budget ) and he became our CTO, introducing me to Model-View-Controller ( MVC ) web application architecture. Later I learned there was a whole cluster of variations about such architectures, mostly trivial. Today I'm studying HTTP caching, and revising what I understand.

An initial HTTP Request, from a HTTP User, is expected to go via a HTTP Client, to a HTTP Server, which Responds in the heuristic of HATEOAS, to provide the client with Hyperlinks to Resources. Conventionally, the client's initial request is a GET ( verb ).

REQUEST HEADERS USED IN CACHING

• Cache-Control: 
• no-cache
• "don't send me a cached response unless the server has freshly revalidated the response"
• no-store
• "don't store any part of the request or response"
• no-transform
• "don't modify the client's request"
• max-age=[seconds]
• "any cache must mark the response as stale, after [seconds] + response-timestamp"
• min-fresh=[seconds]
• "stricter : don't send me cached responses, unless they will be fresh for at least [seconds]"
• max-stale=[seconds]
• "laxer : send me cached responses, as long as they are stale for no more than [seconds]"
• only-if-cached
• "don't send any responses, unless they are already in the cache"
• stale-if-error=[seconds]
• "laxer : send me cached responses, if server responds with 500, 502, 503, or 504, SO LONG AS cached response has another status code, and is stale for less than [seconds]"
• If-Modified-Since: [datetime]
• "if TRUE, send a fresh response; if FALSE, send a bodiless 304 Not Modified response"
• If-None-Match: "[ETag]", "[ETag]"
• "if NONE MATCH, send a fresh response; if ANY MATCH, send a bodiless 304 Not Modified response"
• If-Match: "[ETag]", "[ETag]"
• "if ANY MATCH, ignore and proceed; if NONE MATCH, interrupt and send a bodiless 412 Precondition Failed response"
• If-Unmodified-Since: [datetime]
• "if TRUE, ignore and proceed; if FALSE, interrupt and send a bodiless 412 Precondition Failed response"
• Range: bytes=[range]
  If-Range: "[ETag]"
• "if ETAG MATCHES, AND the resource hasn't changd, send [range] bytes of the resource as a 206 Partial Content response; if NO MATCH, OR the resource has changed, send the resource from the 0th byte"
• Range: bytes=[range]
  If-Range: [datetime]
• "if resource HAS NOT CHANGED SINCE [dateline], send [range] bytes of the resource as a 206 Partial Content response; if resource HAS CHANGED, send the resource from the 0th byte"

RESPONSE HEADERS USED IN CACHING

• Cache-Control: 
• no-cache
• "don't cache response"
• no-store
• "don't store response"
• no-transform
• "don't modify the server's response"
• max-age=[seconds]
• "any cache must mark the response as stale, after [seconds] + response-timestamp"
• s-maxage
• "OVERRIDES max-age=[seconds] for shared caches; IGNORED by private caches"
• stale-if-error=[seconds]
• "any cache may cache and send this response, if in future the server responds with 500, 502, 503, or 504, SO LONG AS cached response has another status code, and is stale for less than [seconds]"
• must-revalidate
• "don't reuse stale responses, when disconnected from the origin server, INSTEAD send a 504 Gateway Timeout response"
• proxy-revalidate
• "ONLY private caches may use stale responses, when disconnected from the origin server; shared caches MUST send a 504 Gateway Timeout response"
• must-understand
• "store the response ONLY if the status code's implications on caching policy are recognised"
• best used with no-store, as the fallback behaviour
• private
• "ONLY private caches may store this response, such as browsers and servers"
• public
• "ONLY shared caches may store this response, such as CDNs and ISPs"
• immutable
• "don't bother to ask server for revalidation, SO LONG AS cached resource is fresh"
• stale-if-error=[seconds]
• "any cache may cache and send this response, if in future the server responds with 500, 502, 503, or 504, SO LONG AS cached response has another status code, and is stale for less than [seconds]"
• stale-while-revalidate=[seconds]
• "any cache may cache and send this response, SO LONG AS response is stale for less than [seconds], AND cache attempts to revalidate the response in the background"
• Vary: [headerKey1], [headerKey2]
• "when responses with [headerKeyN] having M distinct values, each of the M values must not be cached together"
• Expires: [datetime]
• same as Cache-Control: max-age=[seconds] but using an absolute time, instead of relative
• [0] or [-1] forces revalidation
• ETag: "[ETag]"
  
• [ETag] represents a byte-for-byte identical response
• ETag: W/"[ETag]"
• [ETag] represents a semantically equivalent, but byte-wise different response; different is typically due to meta-data, such as CSRF codes
• Last-Modified: [datetime]
• used as by clients to reify If-Modified-Since
• Age: [seconds]
• indicates time this response has been stored in the cache 

RFC 3986 defines Internet resources ( the "R" in URL ) as *nouns*. Theoretically, a single URL should respond with a resource at a single Path, but it may present that resource differently based on Query Parameters. A client's initial HTTP Request : may or may not specify, a demand for raw- or rendered-data. If this context is not specified, the server may have its own reasons for deciding how to Respond.

In 2026, to optimise memory hierarchy, we have the noun phrases : SSR, SSG, ISR, CSR, ESR, SWR, etc. This leads us to seek optimal caching mechanisms for both raw- and rendered-data. A vaguely defined resource might correspond to a complex set of raw-data, and correspondingly a complex set of rendered-data.