Accessing querystring vars

[golgote]

I actually have two questions related to querystring vars, those are just to start a discussion :)

First I was wondering why you prefix the variables with 'arg_' when they are accessed with ngx.var["arg_num"] for example. Is this the way nginx stores them internally ? I thought it could make more sense to just use ngx.var["num"], this way no need to prefix variable names with "arg_". I realize this is a BC break though, so maybe having ngx.vars["num"] or like with PHP, ngx._get["num"] and ngx._post["num"] to make a difference between variables from GET, POST (and COOKIE, ENV actually...).

Then, I was wondering if there was a way to deal with request vars with the same name, for example : ?num=1&num=2
IIRC, mod_lua from Apache 2.4 converts the variable to a table in this case. PHP on the other side insist on having brakets like this : ?num[]=1&num[]=2 which can be handy because it also works with num[x]=1&num[y]=2 to create an associative array.

Maybe all of this could be done on the Lua side if I parse ngx.var["request_uri"] or the body. I just thought it could be easier if it was done in the module directly.

[agentzh]

On Thu, Jan 27, 2011 at 6:30 PM, GitHub noreply@github.com wrote:

golgote reported an issue:

I actually have two questions related to querystring vars, those are just to start a discussion :)

First I was wondering why you prefix the variables with 'arg_' when they are accessed with ngx.var["arg_num"] for example.

If you do read ngx_lua's documentation more carefully, the syntax ngx.var.FOO is how to access nginx variables $FOO from within Lua. So ngx.var.arg_FOO is accessing nginx's special variable $arg_FOO which is documented here:

http://wiki.nginx.org/NginxHttpCoreModule#.24arg_PARAMETER

Is this the way nginx stores them internally ?

Because nginx's builtin variables $arg_FOO already provide this functionality, we do not provide any special interface in ngx_lua.

I thought it could make more sense to just use ngx.var["num"], this way no need to prefix variable names with "arg_". I realize this is a BC break though, so maybe having ngx.vars["num"] or like with PHP, ngx._get["num"] and ngx._post["num"] to make a difference between variables from GET, POST (and COOKIE, ENV actually...).

Yeah, it makes sense to provide native interface to access those parameters just like PHP. We'll work on that.

Then, I was wondering if there was a way to deal with request vars with the same name, for example : ?num=1&num=2

Yeah, for now you need to parse the query string in ngx.var.query_string yourself then...sorry about that.

IIRC, mod_lua from Apache 2.4 converts the variable to a table in this case. PHP on the other side insist on having brakets like this : ?num[]=1&num[]=2 which can be handy because it also works with num[x]=1&num[y]=2 to create an associative array.

Indeed :)

Maybe all of this could be done on the Lua side if I parse ngx.var["request_uri"] or the body. I just thought it could be easier if it was done in the module directly.

Agreed :)

Thanks!
-agentzh

[agentzh]

I've already implemented the ngx.req.get_query_args() method in git master. Could you please give it a try? Please take a look at the documentation for details. Thanks!

[agentzh]

I've also implemented the ngx.req.get_post_args() method :)

[agentzh]

consider it resolved :)

[subnetmarco]

I can't find ngx.req.get_query_args() in the current documentation at: http://wiki.nginx.org/HttpLuaModule

[agentzh]

@thefosk It was later renamed to ngx.req.get_uri_args.

[subnetmarco]

Ok, thanks.

[dessite]

Not sure if it is an issue or works as designed but I found that if you refer to query string by

ngx.say(ngx.var.arg_name)

it will get the query string case insensitive, so no difference if you had "name=nginx" or "Name=nginx" or "NaMe=nginx" in your request, but if you do

local query_string = ngx.req.get_uri_args()
ngx.say(query_string["name"])
ngx.say(query_string["Name"])

it is case sensitive so "name=nginx" is not the same as "Name=nginx" in your request

[agentzh]

@dessite Yes, it is expected.