httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: specifying parameter origin
Date Thu, 05 Dec 2002 03:27:55 GMT
"David Brancato" <> writes:


> 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.  

It might require introducing some "state" variables to track changes
within the various tables if a user alters them (they can do that via
the Apache::Request API).  On the surface, I don't like the idea of 
having variable duplication within the struct itself.

Some RESTless (pun intended :) people scoff at mixing the POST data
with query-string data, so there's some real (albeit small right now) 
interest in providing this functionality.  I've been thinking about it 
for apreq-2 but haven't settled on anything specific. 

> 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.



> 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.

That's not going to happen. Standards-compliance dictates that
table-element order is important to us, just as it is to httpd.

> 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?

Off the top of my head, there's an internal COW hack for apache arrays 
that might be useful here.  I'll look into it some more.  Have you
tried implementing any of this yet in Rivet?

Joe Schaefer

View raw message