> other way, which is really the proper way, is that everything but PHP
> expects duplicate keys: foo=bar&foo=baz which, like PHP, gets turned into
> an array on the back end.
I wouldn't say it's standard to have duplicate keys turned into an
array *without* an array hint like []. Maybe some CGIs do it, but
others ignore duplicates and keep the first, ignore duplicates and
keep the last, or create a comma-delimited string. It really isn't
standard in any way I would feel safe generalizing to "the average"
back end, let alone userland code that can change, say, the JSP way to
the PHP way.
Any parsing of what is still "officially" an opaque string should
preserve as much data as possible unless the user provides a hint
saying "just give me what this kind of back end is expected to parse".
This would mean that without the hint, the returned object has to be
quite complex and precise. Probably have to return a deeper object
that always has arrays so the user doesn't have to keep typechecking.
{
string_value : ['hello']
, other_string_value : ['gbye1','gbye2']
, boolean_value : [undefined,undefined]
}
-- S.
