Static resources and (caching) headers
See original GitHub issueIf I am using static { resources(String) }
how do I customize the cache headers? I have some static resources that I would like to cache forever
Maybe resources
should also take decorating closure a la fun Route.resources(resourcePackage: String? = null, block: (Resource) -> Resource = { it })
?
Issue Analytics
- State:
- Created 6 years ago
- Comments:11 (8 by maintainers)
Top Results From Across the Web
Guide for Caching and HTTP Cache Headers for Static Content
a. HTTP cache headers for images and other static content. In almost all cases, static assets like images, JS, and CSS, do not...
Read more >How to cache static resources using HTTP caching in Nginx
You can customize your caching strategy by using different cache headers, which ensure the freshness of your static content or resources.
Read more >Serve static assets with an efficient cache policy
Learn how caching your web page's static resources can improve ... Configure your server to return the Cache-Control HTTP response header:
Read more >Static resources with Public Cache Control may return CORS ...
Currently there is no ability to control the presence of CORS response headers for Static Resources. However, a Static Resource's response may contain...
Read more >Caching headers: A practical guide for frontend developers
Find out how different headers influence browser cache, how they relate to proxy servers, and how popular services created in React serve ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
So is this fixed in the sense that one can
static { }
blockCachingHeaders
and then duplicate all the same paths for setting their headers?If that is the case then I would not really consider this fixed. Seems to fit the bill for the general case based on content-type but at least in our case this is sub optimal where we have different files of the same type with differing expiry.
No, I don’t think so 😦