Parameter Parsing with Duplicate Parameters

Wondering if this should be the correct behavoir of parameter parsing in Rails.

GET /controller/action?key=value1&key=value2

puts params['key'] # = value1

Currently, if you pass in multiple values with the same key, the FIRST value is the value that is used and available in params. I think this goes against PoLS in that keys defined later in html or on the query string should override any previously defined values for that key. I'm not referring to the ability to create an array using the syntax.

There is no written specification for how to parse incoming data, but it seems logical that you would want the values defined later to be the values you retrieve from your framework. (Most other web technologies follow this behavoir as well, PHP, Django, all the Java crap etc..)

Opinions on this behavoir? I can do up a patch to enable it, not sure what BC effects this would cause since you can't really rely on this behavoir right now anyways.

Bob Silva http://i.nfectio.us/

Take a look at the checkbox form helper. It effectively exploits the current behavior.

jeremy

Hi Jeremy,

For the checkbox code, I wouldn't define that as exploiting the behavior, it's more like working around the problem. If Rails exhibited the "typical" behavior for parameter parsing (treating the incoming parameters as a hash where new values overwrite existing ones), the hidden field would just be listed before the checkbox tag instead of after it.

I was just wondering why the break from convention and if it was a design decision or an oversight and something that can be fixed.

Thanks for the reply. I'll just wrap it up in a plugin.

Bob Silva http://i.nfectio.us/

Jeremy Kemper wrote:

For the checkbox code, I wouldn’t define that as exploiting the behavior, it’s more like working around the problem. If Rails exhibited the “typical” behavior for parameter parsing (treating the incoming

parameters as a hash where new values overwrite existing ones), the hidden field would just be listed before the checkbox tag instead of after it.

Ah, you’re totally right. Could go either way.

I was just wondering why the break from convention and if it was a design decision or an oversight and something that can be fixed.

It was a design decision, but I think your expectation is reasonable.

jeremy