Consider reducing the number of static resource locations that are configured by default

[wilkinsona]

See spring-projects/spring-framework#27538 for some background. We have four default locations at the moment:

• /static
• /public
• /resources
• /META-INF/resources

Lots of apps will only use one of these and some will even use none of them, yet they'll be paying a cost for all four. I think we should consider reducing the number of default locations, or perhaps we can be smarter about how they're configured and avoid passing non-existent locations into MVC and WebFlux.

Reducing the default locations would arguably also make things easier for users as it'll ensure more consistency across apps that are using the defaults.

/cc @rstoyanchev

[rstoyanchev]

The list is now trimmed in both ResourceHttpRequestHandler and ResourceWebHandler, so therefore it shouldn't be necessary to trim it before it's passed, at least not for efficiency.

Note that when the list is trimmed, ServletContext "/" does remain as a location because technically it exists, but it doesn't mean it contains any static resources. I can't think of a good way to tell if it does contain static resources or not at the Spring Framework level, but if there is any further knowledge at the Boot level, that's something that could be filtered out from the list of locations.

[philwebb]

Lets push this back so that the 3.0 upgrade isn't harder than it needs to be.

[sdeleuze]

While working on spring-projects/spring-framework#27619 and spring-projects/spring-framework#29322, I noticed that the /META-INF/resources default configuration has the interesting side effect to make WebJars versioned URLs working out of the box without webjars-locator-core dependency and without any user configuration, which is great given the pretty huge efficiency impact of webjars-locator-core at startup, see this comment for details.

Notice webjars/webjars-locator-core/issues/96 will hopefully allow Spring Framework to support WebJars efficiently in a not too far future (both versioned and version-les URLs) without having to rely on /META-INF/resources default configuration.