Feature #3274
closedmod_expire: HTTP Immutable Responses
Description
RFC 8246 defines the immutable HTTP response Cache-Control extension, which allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.
Suggest somehow adding "immutable" to the "expire" configuration options.
E.g.:
expire.url = (
"/" => "access plus 0 hours",
"/longlife/" => "access plus 1 months;immutable",
"/versioned/" => "immutable",
)
Updated by gstrauss 4 months ago
Please keep in mind that Cache-Control is HTTP/1.1, not HTTP/1.0.
Have you looked at mod_setenv or mod_magnet as solutions?
Alternatively, an age-old solution for maximizing caching is to name assets uniquely, e.g. each image is named with a version number, cached for a long time (say 1 year), and when the image is changed, it gets a new version number and the .html pages which reference the image are updated to use the new name.
Updated by MortenBroerup 4 months ago
gstrauss wrote in #note-1:
Have you looked at mod_setenv or mod_magnet as solutions?
I think mod_setenv would affect all resources hosted on the web server.
The documentation for mod_setenv also refers to mod_expire for Cache-Control headers. ;-)
mod_magnet seems overkill.
Alternatively, an age-old solution for maximizing caching is to name assets uniquely, e.g. each image is named with a version number, cached for a long time (say 1 year), and when the image is changed, it gets a new version number and the .html pages which reference the image are updated to use the new name.
We are already doing that, but would like to add "immutable" to the versioned resources, to prevent the web browsers from checking validity when reloading a page. Refer to:
https://engineering.fb.com/2017/01/26/web/this-browser-tweak-saved-60-of-requests-to-facebook/
PS: We already hacked mod_expire to append ", immutable" to the Cache-Control header, but it's an ugly hack, and I thought others might benefit from this feature too.
Updated by gstrauss 4 months ago ยท Edited
- Status changed from New to Wontfix
- Target version deleted (
1.4.xx)
https://www.rfc-editor.org/rfc/rfc9111.html#name-cache-control
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#immutable
Cache-Control has many, many options and since mod_magnet can be infinitely customized, why should mod_expire be extended for immutable and not all the other options?
Please use mod_magnet or explain why immutable is both a critical optimization necessary for your environment and you are unable to use mod_magnet or mod_setenv
You would not have had to "hack" mod_expire if you had a better understanding of Cache-Control "max-age".
e.g. setenv.set-response-header += ("Cache-Control" => "public, max-age=604800, immutable")
I think mod_setenv would affect all resources hosted on the web server.
Did you see the examples in mod_setenv which contradict your statement?
Please read Configuration: File Syntax
$HTTP["url"] =^ "/static" {
setenv.set-response-header += ("Cache-Control" => "public, max-age=604800, immutable")
}
mod_magnet seems overkill.
Have you quantified that? Or are you guessing?
lua mod_expire sample
PS: We already hacked mod_expire to append ", immutable" to the Cache-Control header, but it's an ugly hack, and I thought others might benefit from this feature too.
You seem to think very highly of your own solutions without having discussed them in the Forums to see what others think of them.
In the future, please ASK QUESTIONS in the lighttpd forums instead of opening issues. See Forums tab near the top of the page.
Also available in: Atom