I’ve tried searching for everything even remotely related to this issue and I found nothing. Neither information that it can’t be done nor anything saying that it would be different than setting custom headers for any other file.
2 header rules processed
All header rules deployed without errors.
For “notifications” it works as intended. But for “backgrounds” so files that I have LFS set-up it does absolutely nothing. Adding a completely new file there didn’t help either. I keep getting “public, max-age=0, must-revalidate”.
Hi, @Pentiado, I’m seeing the same thing. “The same thing”, meaning the header rules are defined correctly but not working for the Netlify Large Media (NLM) assets.
I’ve asked out developers about this and expect to have more information for you soon once I get a response from them.
Just chiming in here that I have the same issue. I’m serving a SQLite db via NLM for use with sql.js to drive a data visualization; the db is immutable, so I would really love to be able to set better Cache-Control headers on it.
Just encountered the same issue and was aimlessly debugging.
Any updates to this? Netlify Large Media serves my needs, except for the lack of caching/custom headers on these files.
Nope. We have no planned changes in this feature, so if you need it, you should not use Large Media, or not use our service. Wish I had better news for you but in the spirit of transparency, you can make the right decisions about how to spend your time (working around it, migrating off it or us, etc) that make the most sense for your business!
thanks for the heads up. would routing the transformed images through a netlify function (with desired headers) be allowed, feasible and performant enough?
Hi, @northamerican. I can only answer definitively for the first part of the question: Yes, it is allowed.
Whether is is feasible or performant enough is the “grey area”.
Answering that portion of the question would require implementing that solution and then testing to see the performance. No such solution exists at this time so there is no way to accurately determine the performance. Once the performance is known, then it can be compared to the requirements to answer the feasibility and performance part of the question.
There is another possible solution. For the files that need custom caching, do not store the files in Large Media. (They can still be in the Git repository, they just cannot be stored using Git LFS.)
Obviously, this second solution isn’t a feasible if you also require the browse time image transformations for those files. However, if you do not require image transformations for the images using the custom headers, then this might workaround the issue for now.
I’ve been using NLM on a few personal projects and the caching headers are a bit of a disappointment for resources that are being transformed via image params. Is there any chance that, even if you aren’t able to enable per-resource caching rules, you might turn on stale-while-revalidate for transformed media?
We will always force the browser to revalidate the local content and return a 304 instead of a 200 if the If-None-Match header matches. If the browser has the local file, I do believe it is shown in the interim.
The cache-control setting wouldn’t affect our CDN and, I think for the reasons above, it would also not affect the local browser cache.
I can also enter the feature request with the additional requirement of also adding a larger max-age setting with the stale-while-revalidate setting. This would still be in conflict with the current caching philosophy, though, and would change site behavior. It is vanishingly rare for us to change how existing sites behave and we tend to only do so if there is a urgent reason for the change.
On the other hand, the feature request for full custom header support with Large Media allows each site owner to decide what is best for them and only be changed if a site owner intentionally created header rule to change their site. On other words, full custom header support doesn’t force any existing sites to change.
Again, I’m happy to enter the feature request if you want me to do so. I just wanted to explain the reasons why I think it is actually less likely to happen than full custom header support for Large Media before proceeding.
Should I still file the feature request for the stale-while-revalidate setting? If so, what max-age or stale-while-revalidate settings would best meet your requirements?
Heyy, I just ran into this, and it’s quite important for me - this site is image content-heavy, and I use the ViteJS build system which allows marking assets with cache-control: immutable, meaning no invalidation is ever needed. Was there any progress on this?
A feature request was never filed as there was no response. After reading the above explanation, do you wish for it to be filed? Even if it gets added, we don’t know if/when it would be implemented.
I don’t really understand what do you mean by ‘there was no response’ - this thread feels like there’s quite a few people interested in that. But yes, I’d love if you could raise this internally - the current behaviour is quite unintuitive and easily overlooked. Though I understand that the LM/CDN is probably using a very different stack from ‘main’ netlify and it could be tricky to implement this without causing issues with your CDN+cache pipeline
Thank you for your assistance!
Oh, I realized you could mean specifically the stale-while-revalidate. No, I believe that’s quite a specific use case and don’t think it would help me. I was talking about the general issue of header rules not being applied on LM, which Luke said he created a ticket about, and I wanted to ask if there was any news on this
Apologies. That’s correct, I was talking about that specific use case. About the actual error of not having headers for NLM assets, the issue is still relevant and not fixed. We’d update the thread if there’s an update.