Unable to retrieve FlashMap when target parameters are encoded [SPR-11504]

[spring-projects-issues]

Yannick Lazzari opened SPR-11504 and commented

When the AbstractFlashMapManager decodes the target request parameters of a FlashMap before saving it, it only decodes the parameter values, not the parameter names. Parameter names are also part of the URL, just like values, so they might potentially also contain characters that were encoded, which is not that uncommon considering the binding path naming convention for array/map parameters that use the square brackets, e.g. '/some/url?params[0]=value1&params[1]=value2' which gets encoded to '/some/url?params%5B0%5D=value1&params%5B1%5D=value2'.

A similar issue had been raised in the past (#14291) but the fix then was to only decode the parameter values (see following commit: 364bb69).

---

Affects: 3.2.4

Issue Links:

• #14291 Flashmap matching logic fails when target params are encoded.
• #16441 Unable to retrieve FlashMap when contains "+"(half-space) in the request parameters
• #17170 Flash attributes not working with spaces in query parameters

Referenced from: commits spring-attic/spring-framework-issues@fed05a9

Backported to: 3.2.9

0 votes, 7 watchers

[spring-projects-issues]

Sébastien Deleuze commented

Rossen Stoyanchev I sent a pull request for this issue and created a sample project in order to reproduce the issue and test the fix.

Even if I think this is not related to this issue, during my tests I found that enabling CharacterEncodingFilter breaks AbstractFlashMapManager#isFlashMapForRequest with Tomcat but not with Jetty when target parameter name or value have a special character. I will make more tests tomorrow and create a new separate issue if needed.

[spring-projects-issues]

Sébastien Deleuze commented

I finally identified why CharacterEncodingFilter broke FlashMap target parameter matching, and this was only (even if tricky) configuration issue.

By default, Tomcat connector has no URIEncoding parameter set on its HTTP and HTTPS connector, so it fallbacks on Tomcat default (ISO-8859-1). So basically there is a mismatch between Tomcat default URIEncoding and the encoding set by CharacterEncodingFilter (UTF-8 in my case). With URIEncoding="UTF-8" explicitly set on HTTP and HTTPS connector, its works flawlessly.

[spring-projects-issues]

Rossen Stoyanchev commented

Looks good Sebastien. The pull request has been merged.

Also see #16099 where the same issue with a URI decoding mismatch between the Servlet container and Spring MVC was also encountered. We are considering some improvements there. We probably can't pick a perfect default, since that depends also on how the Servlet container is configured. However we can provide a way to enforce the URI encoding in UrlPathHelper and also provide better documentation.

[spring-projects-issues]

Juergen Hoeller commented

FYI, I've backported this to 3.2.9 as well...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Yannick, if you got a chance, please give a 4.0.3 or 3.2.9 snapshot a try (see http://projects.spring.io/spring-framework/ for Maven coordinates), and let us know whether it properly fixes the issue for you...

Juergen

[spring-projects-issues]

Yannick Lazzari commented

Will do. Thanks!