To clarify, what I'm saying is that it's standard for a url to submit multiple values as foo=1&foo=2 rather than the non-standard PHP mechanism of foo[]=1&foo[]=2. In MooTools, we have mechanisms to *encode* a URI with such values and they currently only output the PHP methodology, which is non-standard (i.e. now how browsers submit multiple values on their own). Conversely, if we implement the option to *encode* a url in this standard way we need to also provide the same option to *decode* it. I'm not arguing that we shouldn't support all three methods (explode, concat, ignore), but that currently we ONLY support ignore unless the URI uses PHP's brackets.
On Tue, Feb 7, 2012 at 11:50 AM, Sanford Whiteman <[email protected]>wrote: > > your browser will submit: > > > https://www.google.com/?foo=1&foo=2&bar=1&bar=2 > > > This isn't a backend doing the encoding; this is your browser sending a > GET > > request. This is how things *normally* work. > > Did I question this somewhere? I don't think so... > > The question is whether a client-side QS parser should have one, two, > three, or perhaps zero `hints` available as to how it builds its > returned object. You said it's standard for CGIs other than PHP to > parse `foo` into an array. That is simply not true. There are three > major approaches (discard, explode, concatenate) and more servers > in-the-wild running CGIs that *don't* explode the above into an array > than CGIs that do. > > -- S. > > >
