Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <00d001c29c08$7f2381a0$0200a8c0@mach1>
From: "David Brancato" <David@Brancato.com>
To: <apreq-dev@httpd.apache.org>
Subject: specifying parameter origin
Date: Wed, 4 Dec 2002 20:46:20 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I believe this question has been asked previously by someone else but went
unanswered so I wanted to re-ask it.

I want to afford the users of the Rivet module the ability to specify
whether the value of a parameter key is to be looked up in the query string
or the form post or both:

POST /foo.script?a=1 HTTP/1.1
Host: somehost

a=2

In the above request, the parameter "a" has been sent both in the query
string and the form post, with different values (granted this is atrocious
coding practice but the ability to specify a parameter's origin should be
there atleast for defensive purposes).

As it is now, apreq lumps all the parameters into ApacheRequest->parms
leaving no way to differentiate with respect to origin (one would traverse
the parms table and find two a's, not knowing for sure which one was from
the query string and which was from the form post).

One way to differentiate would be to add two more tables to ApacheRequest
called getparms and postparms, while retaining parms. But this would double
memory usage as all the strings would be duplicated. One way around this is
to add elements to the getparms and postparms tables using ap_table_addn.
The getparms and postparms tables would essentially act as different "views"
to the parms table. The problem, of course, with using ap_table_addn is if
the parms table is seriously manipulated during the course of the request,
it could result in getparms and postparms pointing to bad strings.

Another way to afford differentiation is to store the number of query string
elements added to the parms table in something like ApacheRequest->nargs.
Since the lead elements in the parms table are from the query string, nargs
could then be used in for loops as either an offset (for traversing only the
post parameters), an ending point (for traversing only the query string
parameters) or not at all (for traversing the entire table). The problem
with this method is if the underlying structure of tables is ever changed in
future versions of Apache so that elements do not remain in entry order,
nargs would no longer be useful.

So, both approaches have their pros and cons, but both allow parameter
differentiation after the client request has been parsed into ApacheRequest.
Does anyone have any thoughts on these approaches or perhaps a better
approach altogether?

Thanks,
David Brancato
Nessum Technologies