URI encoded commas

[gr0uch]

When I have a query string that looks like this: ?fields[animal]=birthday,type, its proper URI encoded form is: ?fields%5Banimal%5D=birthday%2Ctype. The problem is that when I use de-substitution with the proper URI encoded query, the value of that query parameter is now the string 'birthday,type' instead of the array ['birthday', 'type']. If the query is not properly URI encoded, I get the array value (expected?)

RFC 3986 defines comma as an encoded character.

[geraintluff]

Hmm - although RFC 3986 defines comma as an encoded character, RFC 6570 uses it (unescaped) as a separator for arrays:

{/list}            /red,green,blue

[geraintluff]

OK, so the spec itself makes a distinction about when commas are encoded or not.

I know it's weird, but in that section (with keys := [("semi",";"),("dot","."),("comma",",")]), we have:

{keys}             semi,%3B,dot,.,comma,%2C

Unless we treat , differently to %2C, I don't see a way to successfully deconstruct that URL.

The only option would be to maybe detect the presence of commas, and if none exist then split on %2C instead. However, that would still put us at odds with some expected behaviour, including this semi-official-looking test suite.

[geraintluff]

The underlying issue, I guess, is that although it seems odd, the deconstruction you're getting is correct insofar as is possible with regards to the spec.

If value = "a,b,c", then {value} maps to a%2Cb%2Cc - however, if value = ["a", "b", "c"], then {value} maps to a,b,c, as demonstrated by examples in the spec.

Therefore, since our goal is to reverse-engineer the template as defined in the spec, when faced with a string a%2Cb%2Cc, I think decoding to a single string (not an array) is the most correct thing we can do. Decoding to an array would end up not being round-trip compatible.

Sorry!

[gr0uch]

So according to RFC 6570 it's intended to leave the comma unencoded in case of lists, hmm. Okay that makes sense I guess.