Rails - Mar 2006 - @params["aKey"] and multiple aKeys in request

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.

On 3/8/06, G?bor Sebesty?n <segabor@gmail.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060308/d56c82a7/attachment.html

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

On 3/9/06, G?bor Sebesty?n <segabor@gmail.com>
wrote:
>
> 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?
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060309/eb52d36a/attachment.html

On 3/9/06, Josh on Rails <rails@thewehners.net>
wrote:
> 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!"
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

On 3/9/06, Isaac Reuben <isaac@reuben.com> 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.