A simple showcase of this error can be found here: https://github.com/bennypi/thymeleaf-and-springboot
Expected behaviour
The expected behaviour can be seen when changing the spring boot version to 2.5.6. With this version, the linked css can be retrieved and the form POST is working.
Current behaviour
Starting with spring boot version 2.6.0 and still present in 2.6.1, requests with the jsessionid parameter are not processed correctly but lead to errors on the server. A call to a CSS-file with the jsessionid parameter leads to a 404, the form POST request with the jsessionid parameter also leads to a 404. The page starts working again when the page is refreshed in the browser because the browser then sends a cookie with in the request which in turn removes the jsessionid parameter in the links in the HTML.
I am not completely sure if this indeed a bug in spring boot or if thymeleaf must make changes so that it is compatible with spring boot 2.6.0 and newer, but I don't see anything in the release notes that could be a reason for this changed behaviour.
Comment From: ztomic
This is due to path matching strategy change to pattern based instead of ant. I've had same issue.
Workaround is to configure ant_path_matcher as matching strategy.
spring:
mvc:
pathmatch:
matching-strategy: ant_path_matcher
https://gitter.im/spring-projects/spring-boot?at=61ae129e8f98cb0811aa9c04
Comment From: bennypi
Thanks for the reply, I will test this workaround.
Nonetheless, I am still not sure what to think of this: AFAICT thymeleaf uses spring for URL rewriting. And spring rewrites the URLs into a format that spring can no longer process. How is this supposed to work with the new path matching strategy?
Comment From: philwebb
I think this might be a Spring Framework issue. Thymeleaf is calling HttpServletResponse.encodeURL(url) which adds ;jsessionid=....
Spring Framework has a ResourceHttpRequestHandler class that attempts to resolve resources. This line reads HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE which contains the jsessionid causing the resource to not be found.
I'm not sure if the value of PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE is wrong, or if the ResourceHttpRequestHandler should cleanup the path.
Comment From: philwebb
Transferring to the Framework team. Run the sample and do curl 'http://localhost:8080/css/main.css;jsessionid=27DE19AF0DE98353ECE4958BD868C6C5' to replicate the problem. It should return the css, instead it 404s
Comment From: rstoyanchev
In most places we use PathPattern to pattern matching to the input RequestPath. The matching uses PathSegment#valueToMatch() which returns a decoded path, also cleaned from path parameters. For static resources, however, we use the full path based on PathContainer#value(), which is the original, raw path. We might need to expose an additional PathContainer#valueToMatch() that returns the path cleaned from path parameters.