The following pseudo-code shows how the cache refresh logic works:
if “Expires” and “Last-Modified” headers are missing then validate file.
else if Cache modification time + Maximum age < Current time then validate file.
else if “Last-Modified” header is present and “Expires” header is not present and Last-Modified time + Last-Modified time factor < Current time then validate file.
else if “Last-Modified” header is present and Last-Modified time + Minimum age > Current time then validate file.
else if “Expires” header is not present and Cache modification time + Revalidate age < Current time then validate file.
else send file unvalidated.
Validation is accomplished by sending an “If-Modified-Since: <timestamp>” header with the request, the Web server will respond with code 304 if the file hasn't been modified.
Since not all Web servers support this, Middleman will also check the Last-Modified header and send a cached response if it maches the cached file's Last-Modified time.
Middleman will honor the following directives sent in the Cache-Control header by the client:
no-cache - Don't send cached copy (Middleman makes an exception and will revalidate it instead)
no-store – Same as no-cache
min-fresh=<seconds> - Cached file will only be sent if it will remain fresh for this long.
max-age=<seconds> - Cached file will only be sent if it is no older than this.
max-stale=<seconds> - Send cached file if it has been stale for longer than this amount of time. If the cache file is infact stale, a Warning header will be sent with the response indicating this.
and the following directives from Web servers:
no-cache – Don't cache, if the “Violate RFC” option is selected it will be cached anyways but always validated.
no-store – Same as no-cache
must-revalidate – The cache file will be validated on every request.
max-age=<seconds> - The file will expire after being cached for this long.