A query strings like "x=1&x=2&x=3" should be decoded into list of strings: ["x": ["1", "2", "3"]]

Now Uri.decodeQuery returns only last match ["x": "3"], and has a inappropriate signature too (it returns Str:Str). It's ok and even more useful in cases when you don't deal with lists, but doesn't handle a situation when you need them.

Both Uri and the web APIs all work with Str:Str only. True some of the RFCs say you can do this. But in the real world it is not well supported, extremely rarely used, and probably a really bad idea to use it. So I kept the APIs simple and easy to use at the expense of handling odd conditions like this.

Actually going back and looking at WebUtil, what I did for HTTP headers was to append them together using the comma. That is probably what Uri.query should do too, I will take a look.

That's ok, but there's no other way to handle these situations, at all. Let's took this form for example:

Whom to notify?
[ ] brian
[v] andy
[v] tonsky
[submit]

If the list of persons is dynamic, you'll need to create a list of checkboxes with the single name and different values:

<input type="checkbox" name="user" value="brian"/>
<input type="checkbox" name="user" value="andy"/>
<input type="checkbox" name="user" value="tonsky"/>

Are forms of such kind rare? Or do you have an another way to handle them?

For example, Django has two different methods to extract param values: one for extracting parameter's single (first) value and another to extract list when you expect it. I think, it's a good compromise between API usefulness and completeness.

Renamed from Uri.decodeQuery does not understand list of values with same name to Uri.decodeQuery does not handle duplicate keys

Promoted to ticket #1276 and assigned to brian

Ticket resolved in 1.0.56

I pushed a fix - changeset.

If duplicate keys are detected it concats the values using comma:

fansh> `?x=1&x=2&x=3`.query
[x:1,2,3]
fansh> `?x=1&x=2&x=3`.query["x"].split(',')
[1, 2, 3]

That seems like a good solution for the existing API. Plus the queryStr is still maintained to pass to other APIs or to create a new API if we decide we really need to parse into a Str of Str[].

All the query string APIs I know support a Str:Str[] concept (where the Str[] is normally size 1). I'm OK with comma separation as a default for Str:Str, but do believe that the Str:Str[] form is needed on occasion.

but do believe that the Str:Str[] form is needed on occasion.

for &x=a%2Cb&x=y -> &x=a,b&x=y -> a,b,c it is definitely better than extra escaping to preserve the original meaning

Edit: better formulation

thx brian!