StaticFileServer: Make cache-control configurable, remove GWT references, allow testing in dev mode

[enver-haase]

Description

StaticFileServer.getCacheTime() has three hard-coded cache durations based on filename patterns originating from GWT conventions. These patterns and their values are not configurable and cannot be tested in development mode.

Current behavior (production mode)

Filename pattern	Cache-Control header	Duration
Contains .nocache.	public, max-age=0, must-revalidate	none
Contains .cache.	max-age=31536000	1 year
Everything else	max-age=3600	1 hour
Any file in dev mode	no-cache	always, regardless of pattern

Source: StaticFileServer.java, methods getCacheTime() and writeCacheHeaders().

Issues

1. Cache durations are not configurable

The three cache durations are hard-coded. There is no way to configure them via a system property, environment variable, or deployment configuration parameter. Users who need different cache policies (e.g., 30 minutes for static downloads) must resort to servlet filters with HttpServletResponseWrapper hacks to prevent StaticFileServer from overwriting the Cache-Control header.

2. Dev mode unconditionally sets no-cache

writeCacheHeaders() ignores getCacheTime() entirely in development mode and always sets Cache-Control: no-cache. This makes it impossible to test or verify cache behavior during development. The production cache behavior can only be observed after building with -Pproduction and deploying, which slows down the development feedback loop.

3. GWT references should be removed

getCacheTime() contains a comment block explicitly referencing GWT conventions and linking to the GWT documentation:

/*
 * GWT conventions:
 *
 * - files containing .nocache. will not be cached.
 *
 * - files containing .cache. will be cached for one year.
 *
 * https://developers.google.com/web-toolkit/doc/latest/
 * DevGuideCompilingAndDebugging#perfect_caching
 */

GWT was removed from Vaadin years ago. These references are misleading and should be cleaned up.

4. Relevance of .cache. / .nocache. patterns is questionable

The .cache. and .nocache. filename conventions were a GWT artifact. It's unclear whether these patterns are still meaningful in modern Vaadin applications. No Vaadin documentation references them, and users are unlikely to name their static resources following GWT conventions. The default 1-hour cache for all other files may also not be appropriate for all use cases.

Suggested improvement

Make the cache-control behavior configurable, for example via system properties or Vaadin deployment configuration:

• vaadin.static.cache.default — default max-age in seconds (currently 3600)
• vaadin.static.cache.long — max-age for .cache. files (currently 31536000)
• Allow dev mode to optionally respect cache settings (e.g., via a flag like vaadin.static.cache.devmode=true)

Vaadin version

Verified in 24.9.13 and 25.0.6 — code in StaticFileServer.getCacheTime() and writeCacheHeaders() is identical in both versions.

[enver-haase]

The underlying reason for this request is "performance", that is: one user reports they have massive amounts of data that need to be re-transferred every hour even though they are unlikely to ever change. Their customers suffer from that e.g. in slow WiFi connections, such as in German ICE trains.

[Artur-]

What is the actual problem here, or in other words, how are the resources loaded? #23544 solves this for stylesheets without requiring the user to define any timeouts as all resources will be cached forever and only reloaded when they change

[enver-haase]

The resources are loaded like here:
https://github.com/enver-haase/filecache
In the two commits, work-arounds for Spring/Maven and CDI/Gradle are given.
Since the latter is Servlet API, I assume it would work in any way.

The original report still stays: Vaadin does not let us configure the cache time, surprises with Development vs Production inconsistencies and within Production with a non-configurable hardly-known default and its weird exceptions based on the file names.