Skip to content

Enhance ResourceHttpRequestHandler with ResourceResolver strategy [SPR-10933] #15561

Closed
@spring-projects-issues

Description

@spring-projects-issues

Rossen Stoyanchev opened SPR-10933 and commented

Currently ResourceHttpRequestHandler uses a simple algorithm that takes the request path and tries to find a matching resource under one or more pre-configured locations, either under the web application root or on the classpath (e.g. under /META-INF/public-web-resources"). In order to implement more sophisticated resource serving, it should be possible to configure additional strategies for resolving the request path to a Resource, possibly even transforming the resource along the way.

A common use case is fingreprinting URLs to allow aggressive cache headers while still detecting changes when they occur (#14944). For this scenario to work a request path of "foo-e36d2e05253c6c7085a91522ce43a0b4.css" should resolve to resource "foo.css". The reverse should also be possible, i.e. a view should be able to look up the actual URL to use for "foo.css", e.g. "foo-e36d2e05253c6c7085a91522ce43a0b4.css".

Additional use cases include detecting gzipped files (extension ".gz") and serving them instead if the client accepts "gzip" content encoding, locating "css.less" files where ".css" is requested, etc.

In addition to locating resources, it should also be possible to transform resources. For example less-to-css transformation, gzipping, js/css minifying, etc.


Affects: 3.2.4

Issue Links:

3 votes, 10 watchers

Metadata

Metadata

Assignees

Labels

in: webIssues in web modules (web, webmvc, webflux, websocket)type: enhancementA general enhancement

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions