Trying around with per file headers and various other things, I finally got a solution using rewrite and proxy:
localhost:1313 {
# cache headers for static files
rewrite {
if_op or
if {path} has /images/
if {path} has /css/
if {path} has /fonts/
if {path} has /icons/
to /x-cache-header/{uri}
}
proxy /x-cache-header/ {
without /x-cache-header
upstream localhost:1314
transparent
header_downstream Cache-Control "max-age=172800"
header_downstream -Server ""
}
# resource hint + cache header for index
rewrite {
if {path} is "/"
to /x-index-header/{uri}
}
proxy /x-index-header/ {
without /x-index-header
upstream localhost:1314
transparent
header_downstream Cache-Control "no-cache, max-age=86400"
header_downstream +Link "<https://stats.example.com>; rel=preconnect"
header_downstream +Link "</css/main.css>; rel=preload"
header_downstream +Link "</images/bg.jpg>; rel=preload"
header_downstream +Link "</css/images/overlay.png>; rel=preload"
header_downstream -Server ""
}
}
localhost:1314 {
}
This gives us the possibility to set headers using regexp, paths etcâŚ
Furthermore this can be used to enable various plugins on a per file, basis. For example cors or minify could be done on one file only instead of on a whole path.
Yeah you are right, I copied an old version. I edited it to reflect the running version.
It was not only âif_op orâ, which was needed, but also (which is quite unintuative) â-Server âââ. Without the empty string at the end it canât parse the caddyfile.
Using rewrite alone wouldnât be sufficient? Not sure, if it makes sense that we are adding if support to various middlewares, when we already have a specific rewrite middleware, which should be leveraged in my opinion. What would the reasoning be for duplicating the if code/functionality within header? Easier caddyfiles? Less overhead?