Flashmap matching logic fails when target params are encoded. [SPR-9657]

[spring-projects-issues]

David Victor opened SPR-9657 and commented

In our app we handle some request parameters which contain unicode characters.
Our web.xml has the familiar org.springframework.web.filter.CharacterEncodingFilter enabled to encode using UTF-8.

One of our handler methods in a controller class redirects on success - and we add a success alert message to the flashmap in RedirectAttributes. We also add a couple of attributes to the "redirect model". This ends up with an encoded parameter in 'targetParams' - which fails to match to the relevant request via isFlashMapForRequest() in AbstractFlashMapManager.

Will try to add more useful detail - but am on limit of my knowledge here, and been banging head against this for a day now. The impact is that within our app the 'XXX successfully complete' flash message in the UI does not appear - due to not matching the flashmap - for encoded parameters. Fortunately these are in the minority - but its quite odd when the message mostly appears - and then sometimes doesn't. :-)

---

Affects: 3.1 GA

Sub-tasks:

• Backport "Flashmap matching logic fails when target params are encoded." [SPR-9701] #14335 Backport "Flashmap matching logic fails when target params are encoded."

Issue Links:

• Unable to retrieve FlashMap when target parameters are encoded [SPR-11504] #16129 Unable to retrieve FlashMap when target parameters are encoded
• Flash attributes not working with spaces in query parameters [SPR-12569] #17170 Flash attributes not working with spaces in query parameters

[spring-projects-issues]

Rossen Stoyanchev commented

The CharacterEncodingFilter sets the encoding of the request which is for the body and in this case the parameters are from the query string. Have you checked what encoding your servlet container uses for the URL and if there is a way to configure it?

[spring-projects-issues]

David Victor commented

We are using Tomcat 6 - its setup as below.

<Connector protocol="HTTP/1.1" URIEncoding="UTF-8" 
           connectionTimeout="20000" 
            />

Will keep looking.

[spring-projects-issues]

Rossen Stoyanchev commented

It does look like an issue. I've added a project that demonstrates it and will try to address it soon.

[spring-projects-issues]

David Victor commented

Thanks Rossen.

Been looking more today.

For now have added a workaround for our app - have extended DefaultFlashMapManager and overridden isFlashMapForRequest
Then have just done a decode on the targetValue prior to attempting to match it.

i.e.

val = UriUtils.decode(targetValue, "UTF-8");
// then try to match on val ...		

[spring-projects-issues]

Rossen Stoyanchev commented

This is now fixed in master and will also be backported to 3.1.3.

[spring-projects-issues]

Yannick Lazzari commented

I know this is an old bug but I just stumbled onto the same problem. Before I reopen the issue I just wanted to double-check: is there a good reason we only decode the values of the request parameters and not their names as well? After all, they are part of the URL just as much as the values, no? I've tracked down the commit that fixes the issue (364bb69). I have this exact problem but my encoded characters are in the name of the parameters, not the values, 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'.

If you agree, I would re-open the issue.

[spring-projects-issues]

Rossen Stoyanchev commented

Well you cannot re-open this issue as it is "closed" as it was already released and that will never change. You can open a new ticket with a new description. We'll link the two as related tickets.

[spring-projects-issues]

Yannick Lazzari commented

Done: https://jira.springsource.org/browse/SPR-11504.