Backport StaticFileHandlerFactory to V14

[stefanuebe]

The vaadin servlet sets a fixed cache time for any static resource delivered by it when in production mode. This fixed cache time is one hour and cannot be modified. One hour is very short for static resources, that unlikely change for a long time (e.g. icons / images) and leads to additional reloads of the same resources during the day. While it is possible to implement a custom servlet, that takes care of providing static resource, it might help devs to use this out-of-the-box feature and simplify their development process, when that value can be configured dynamically somehow.

// StaticFileServer.java
protected int getCacheTime(String filenameWithPath) {
    if (filenameWithPath.contains(".nocache.")) {
        return 0;
    }
    if (filenameWithPath.contains(".cache.")) {
        return 60 * 60 * 24 * 365;
    }

    return 3600;
}

Description of the bug / feature

The fixed 3600 seconds returned in getCacheTime(String) should be customizable in some way. Potential ways to do that:

1. a config property for the servlet, that is set at startup time, e.g. productionMode.staticFileCacheLifetime with a default value of 3600
2. the possibility to set a callback to the existing static file handler to obtain the cache life time
3. the possibility to set a custom StaticFileHandler instance to the vaadin servlet

I personally would prefer option 3 as it provides additional flexibility for customization.

Versions:

- Vaadin / Flow version: Vaadin 14.6.8

[knoobie]

Isn't that already possible with https://github.com/vaadin/flow/blob/master/flow-server/src/main/java/com/vaadin/flow/server/StaticFileHandlerFactory.java and custom StaticFileHandler because your method is protected?

[stefanuebe]

Indeed. I was not aware of that factory class, since I tested around in V14, where it is not available (at least not 14.6.8). Thanks for the hint.

[stefanuebe]

So the question is, if this factory class / feature will be backported to V14?

[mshabarov]

I don't see any obstacles for back-porting it to the next flow LTS (flow 2.8). This is considered as an enhancement, so I'm not sure we should add it to recently released 2.7.

[denis-anisimov]

@Legioth : should we backport this into 2.x since tis is a new feature ? Which version ? 2.8 ? But it doesn't even exist yet.

[Legioth]

Backporting seems to make sense from a technical point of view. The biggest concern is related to whether the effort would be worth it, but that's more up to @mstahv to determine.

I agree that this is a new feature which means that it would target an upcoming Vaadin 14.x (Flow 2.x) release, e.g. Vaadin 14.8 and Flow 2.8. If a branch doesn't exist yet, then it can be created as part of backporting (if it's decided to backport).

[mstahv]

@stefanuebe Is this still an issue in your project?

[stefanuebe]

@stefanuebe Is this still an issue in your project?

Yes

[mstahv]

Then let's do it as it looks an easy task. If it is the only feature in next 2.x version, we can adapt the release procedures to correspond the size of changes.