mirror of
https://github.com/open-webui/open-webui.git
synced 2026-07-17 08:21:12 -05:00
[GH-ISSUE #17382] feat: Path-based Cache-Control Headers for Mixed Content Types #18261
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#18261
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @calebhansard on GitHub (Sep 11, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17382
Check Existing Issues
Problem Description
When the
CACHE_CONTROLenvironment variable is set, both static assets and dynamic content share the same cache policy. This causes dynamic workspace content (models, knowledge files, prompts) to become stale until the browser cache expires. While caching significantly improves performance, the inability to see real-time updates without manually clearing cache makes this feature impractical for production use.Desired Solution you'd like
Implement path-based or content-type-based Cache-Control configuration:
Cache-Control: public, max-age=31536000, immutableCache-Control: no-cache, must-revalidateCache-Control: private, no-cache, must-revalidateAlternatives Considered
No response
Additional Context
Cache-Control header
@decent-engineer-decent-datascientist commented on GitHub (Sep 17, 2025):
I have to agree with this. While cache does increase the performance by an incredible margin, it also caches stuff that it just shouldn't. For example if I delete a folder with cache enabled, the delete occurs and is reflected in the DB, but the front end does not mirror this (because the call to get folders is cached)
Either through more granular control or just exclusions, this does need to be looked at. The current cache_control approach breaks the front end.
@joni-graham commented on GitHub (Sep 23, 2025):
Agree that this is an important enhancement to allow caching to be an effective tool for scaling.
@Stchizen commented on GitHub (Sep 23, 2025):
This would benefit our deployment as well.
@swiftdev29 commented on GitHub (Oct 21, 2025):
+1
It improves performance significantly, but some very basic functionality is sacrificed. The loading of the model page can definitely be cached but the sidebar with chats shouldn't be. Is there any update/PR for this?
@pm-priyeshpotdar commented on GitHub (Oct 28, 2025):
+1
@rozatoo commented on GitHub (Dec 16, 2025):
+1
@Classic298 commented on GitHub (Dec 21, 2025):
updated the docs around this a while ago so it is handled on NGINX end with an example. is this still needed to be handled on open webui end?
@kirkegaardk commented on GitHub (Jan 22, 2026):
Do you see any benefits having it within the application itself? The original PR appears more security related than performance, which may have put this consideration out of scope and could explain it's a broad cache application. It seems reasonable to have this at an ingress level and outside the application itself, but honestly am learning as I read. Hence my question here.
Unfortunately NGINX Ingress is retiring and we're looking at Gateway API, which appears not to natively support HTTP caching. However, Varnish does and is something I an looking into as well. Not sure if anyone has worked with that before, but it appears to fit the bill for page caching with more granular controls.
@Classic298 commented on GitHub (Jan 22, 2026):
@kirkegaardk
Honestly, not really.
By having multiple different env vars or complex JSON structures and having to modify 100s of files to correctly apply the caching everywhere - that's a TON of work for something that can be done with 40 lines of nginx config by just setting js, html, css, images, etc. separately and done
@Classic298 commented on GitHub (Jan 22, 2026):
Yeah thinking about this again; adding multiple different cache control env vars or other means of configuration (which is excessive to have multiple different env vars or one big one with a json object or something that then gets parsed) and correctly apply all the different configs across all relevant files and endpoints is A LOT of work and needs a lot of testing too - and I can already see many users complain about assets being cached (many do not want caching at all for personal deployments or dev setups).
Also - you can really achieve the same result with NGINX and some simple config there.
You can get very very good results by just creating a few location blocks for different file types and endpoints and ... Open WebUI does not have to introduce new config options for this.
Should serve everyone