@params["aKey"] and multiple aKeys in request

Rails
1

Hi,

I’ve actually run into an interesting problem and no idea how to fix
it. In request parameters i have multiple “url” keys like this:
url=www.abc.com&url=cnn.com&url=…
But @params[:url] has only the latest value for “url” key instead of
having values kept in array.
So what’s next? Is there way out of this issue?

Thanks,

Gábor

PS.: I use rails 1.0.0 and running my app in WEBrick.

2

On 3/8/06, Gábor Sebestyén [email protected] wrote:

In request parameters i have multiple “url” keys like this:
url=www.abc.com&url=cnn.com&url=…
But @params[:url] has only the latest value for “url” key instead of
having values kept in array.
So what’s next? Is there way out of this issue?

You’ll need different keys. Are you manually generating that URL?

You may need to escape the string (I’ve used this with POST, not with
GET)
but you may be able to use:

?url[]=www.abc.com&url[]=www.cnn.com&url[]=www.example.com&

Which would give you an Array.

@params[:url] = [ ‘www.abc.com’, ‘www.cnn.com’, ‘www.example.com’ ]

– Joshua

3

It’s weird. HTML standard allows using a key more than once. I checked
this in irb and Ruby’s CGI::parse(…) parses my test cases in desired
way and returned key - value array pairs back.

myBook:~ segabor$ irb
irb(main):001:0> require ‘cgi’
=> true
irb(main):002:0> CGI::parse(“url=a&url=b”)
=> {“url”=>[“a”, “b”]}

As far as I know RoR inherits Ruby’s cgi features and uses CGI::parse
to handle incoming queries. So what make it wrong them?

Gábor

4

On 3/9/06, Josh on Rails [email protected] wrote:

“that’s better!”
Just so you know, the order these are parsed in is not guaranteed (it
won’t necessarily be the same order as in the url). So var could end
up as “value” or “other_value” depending on the whims of $deity
($deity most likely being your web server in this case – appropriate
if you are using Zeus). They usually are parsed in url string
order, but don’t depend on that.

Adding [] to your vars reduces ambiguity; it’s clear what you meant to
happen.

It also lets you know if the variables are going to be arrays or not.
var[] will always be an array (even an empty one), while var will
never be. Otherwise you’d need to test ALL of your variables to see
which they are.

  • Isaac
5

On 3/9/06, Gábor Sebestyén [email protected] wrote:

As far as I know RoR inherits Ruby’s cgi features and uses CGI::parse to
handle incoming queries. So what make it wrong them?

Well…

  1. I’m pretty sure you mean HTTP, not HTML. HTML is the Markup Language,
    HTTP is the Transmit Protocol.

  2. If HTTP defines it as allowed, that only means that the server layer
    doesn’t generate an error. If it weren’t allowed in HTTP, Apache or
    WebBrick
    or Lighty would throw a “Bad Request” back at the client before Rails
    saw
    it.

  3. I don’t know if, or to what extent, Rails uses CGI::parse for query
    string parsing. Somebody would have to look at the source code to say
    for
    sure.

  4. I’m just guessing, but I imagine that Rails parses requests the way
    it
    does to reduce ambiguity. I, at least, tend to think of

?var=value&var=other_value&

as

var = value
“no, wait, I changed my mind”
var = other_value
“that’s better!”

Adding [] to your vars reduces ambiguity; it’s clear what you meant to
happen.

Again, I’m just guessing here, but I imagine that’s easier for the
parser to
parse, too.

6

On 3/9/06, Isaac R. [email protected] wrote:

It also lets you know if the variables are going to be arrays or not.
var[] will always be an array (even an empty one), while var will
never be. Otherwise you’d need to test ALL of your variables to see
which they are.

You already need to test all of your variables if you want to be sure.
Since params are submitted by a client, params[:id].class could be
String, Array, or Hash.