Consider if we should always register ResourceUrlEncodingFilter

[philwebb]

Commit dd561d1 add ResourceUrlEncodingFilter beans for ThymeleafAutoConfiguration and VelocityAutoConfiguration. Should we push this up an always register it? Will it do any harm if it's always on?

[philwebb]

/cc @bclozel @snicoll

[philwebb]

Should also be conditional on ResourceProperties.chain.enabled

[bclozel]

That filter wraps ResourceUrlProvider, which assists with writing URLs in templates with the resource chain.

Now this particular filter ResourceUrlEncodingFilter is only useful for template engines that use HttpServletResponse.encodeURL, namely JSP, Thymeleaf, Velocity (and others?).
Registering globally such a filter would not do any harm, but doing so:

• will only help JSP users
• will be a (small) performance penalty for all other webapps

Registering it conditionally with ResourceProperties.chain.enabled is indeed a good solution: it's also registering that filter less aggressively for other template engines. So yes!

I'm wondering if we need to spend time and resources finding solutions for other template engines. Right now, I don't know if Spring Boot wants to be in the business of providing template helpers/macros for the ones that aren't supported yet (JMustache, Groovy Markup Template, etc).

Some template engines don't natively support helpers/macros, and you basically have to register those in the modelMap for all views - see this example for Groovy Markup Template.

[snicoll]

It's much more challenging now. spring.resources.chain.enabled is actually enabled if either that property is set or if any of the strategy is enabled (that is spring.resources.chain.fixed.enabled or spring.resources.chain.content.enabled). In practice, we'd need the ResourceProperites in a condition to figure out if it applies or not. Seems like quite a lot of work at this point.