apache cgi-bin shell script number of arguments

[John Kittel]

hp-ux 11.11, apache 1.3, Internet Explorer 6

Running into a problem with a cgi-bin shell script determining number of arguments passed in from the request...

test case: if I use inetnet explorer to invoke a test cgi-bin shell script on HP-UX with apache using this syntax in the browser address bar:

http: //hpserver/cgi-bin/query/t.sh?1+

where test shell script is like this:

#!/bin/sh
set -f
echo "Content-type: text/plain"
echo ""
if [[ $# != 2 ]]
then
echo "error: should be 2 args. Number of args is $#"
echo "exiting..."
else
echo "OK, called with 2 args, |$1| |$2|"
echo "continuing..."
fi


... the result sent back to the browser is:

OK, called with 2 args, |1| ||
continuing...

I need the script to be able to determine valid number of arguments in requests. This request (above) should meet the test in the script, [[ $# != 2 ]] , shouldn't it?

and

[Dennis Handly]

What's the intention of the "?1+"? Was the "+" suppose to be the second arg? I thought "&" was the separator? Or is "+" changed to a space?

>if [[ $# != 2 ]]

This is not the proper syntax to check for integer compare. You are doing pattern matching. (It probably should still work.)
The correct syntax is:
if [[ $# -eq 2 ]]; then

>This request (above) should meet the test in the script,

It is almost as if you are getting "1" and then an empty string.

[Steven Schweda]

> It is almost as if you are getting "1" and
> then an empty string.

At _least_ almost, I'd guess.

What happens with these?:

?a
?a+b
?+b

I'd guess that you'll see a pattern.

[Torsten.]

I have no such old apache to test, but if I try this with apache 2 I get

/cgi-bin/test-cgi?1+
...
argc is 1. argv is 1.

but

/cgi-bin/test-cgi?1+2
...
argc is 2. argv is 1 2.

because "+" means "" for the server, because if you use a form and input a value with a space, for example

name= my name

the browser will convert this to

name=my+name


Note: when using forms (and what else?) you will specify the method (post or get), this will made the difference and all depends on this.


Depending on your needs you should handle the QUERY_STRING variable and disassemble the values from there.

[Ralph Grothe]

As Torsten mentioned,
a CGI script/program executed by the webserver is supplied with the CGI environment.
For HEAD and GET requests any parameters passed to the CGI script will be available in the environment variable QUERY_STRING.
The common method thus is to parse and decompose as well as "urldecode" the parameters from there.
For all sorts of programming/scripting languages there exist CGI libraries/modules that should be used instead of (re)implementing the parameter parsing and other common CGI stuff (e.g. providing correct HTTP response headers) oneself, because this is prone to errors and inadvertent security holes.
However, if you cannot resist the specs should be consulted, e.g. http://www.ietf.org/rfc/rfc3875

[John Kittel]

meaning of the "?1+" :
this script is test case, to demonstrate problem in production scripts called by programs (not user sitting at keyboard/web browser). Called several thousand times per day by programs on several different computers. Also, for debug, I am reproducing the problem by calling from web browser. Scripts should always be called with 2 arguments, but I noticed sometimes they get callled mistakenly with one arg and a +, and script fails to take the error exit.

?a - looks like 1 arg.
?a+b - looks like 2 args. This is how all of the correct (99.9%) calls look.
?+b - can't try it right now. (I'm not at work. I'm on "vacation" 'til Monday.)

When I get back to this on Monday I'll look into the cgi environment variables, esp. QUERY_STRING.

Thank you.

[John Kittel]

I think there is a bug or design flaw somewhere with web browser, apache, shell, - in that when request is like "...?1+" - there is really only 1 argument, even though the "+" means another argument is to follow, there is really no second argument. Yet the shell variable $# = 2, and the value of $2 is null.

However, the CGI QUERY_STRING variable does show "...1+", so I will parse that.