Added some comments

Thanks @schmitch

This bug and related fix deserve an immediate 2.5.8 release.

@alexdupre It's out now.

I found another regression. If the query string contains eg. "key=1,2,3" and the commas are not PCT-encoded, the request.getQueryString("key") returns just "1" instead of "1,2,3", as in "key=1&key=2&key=3" scenario. The comma is so parsed as a value delimiter, is it intended?

I don't think it's intended, because "key=1;2;3" that uses another sub-delim allowed character is parsed as a single query param of value "1" :-(

@alexdupre that is intended. getQueryString("key") will get the first item of the query strings. even if you have &filter=1&filter=2 it would return 1 (and that happened to be there for a while) on getQueryString("filter") at the moment we only treat , as value delimiters. (I regret the change already, wasn't worth anybodies time).

But if you want to add more you could probably add yourself to the discussion in: netty/netty#5820

We may change it so that getQueryString("filter") will return a List<String> in 2.6.x, but at the moment the query parsing and how it will work is WIP in 2.6.x

I'm using bindFromRequest in some of my controllers, to handle params serialized with Angulars httpParamSerializer. The uri is something like query=item1,item2,item3
From 2.5.7 (its happens in 2.5.8 too), this results in only the first item of the query being parsed. I guess this relates to what @alexdupre is saying too. But if I use the queryString.get("query"), "item1,item2,item3" is returned.

I would expect the binding to work though, or is this changed from now on?

I don't know how is your Form, you should probably change the field from text to list(text) or something like that.

Changing it to a list does not help. Probably makes sense to, since its just a value for the parameter, that happens to be comma separated.

I don't know if this a bug, and I should create a separate issue for it.
Or I need to change my code, either way, it started after the 2.5.7 upgrade. And have the same behavior in version 2.5.8.

Its seems to me as, a somewhat big breaking change, for a minor update?

@arnbak yeah I've didn't seen a lot of edge cases, I created a PR that reverts it: #6560