You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2002/08/19 07:51:50 UTC
Adding apreq-2 to httpd-2.0
The apreq developers would like to see apreq-2 [*]
make its way into the apache 2 distribution. Here's why:
1) Having a built-in library for parsing cookies, url-encoded
query strings, and POST data would be useful for other bundled
core modules, e.g. mod_usertrack, mod_isapi. It would also
provide this functionality to other communities that already
depend on it in some way (mod_perl, mod_dtcl, mod_php). The
C/C++ programmers that currently use it would also benefit.
2) Other ASF projects that aren't familiar with apreq would
be better served by adopting it instead of providing the
equivalent functionality themselves. apreq is reasonably fast,
secure, and standards-compliant. apreq-2 is an improved
version that is ported to work with httpd-2.0.
3) We (the active apreq developers) will support, develop and
improve the library. We're not asking the httpd developers
to take over those responsibilities for us; but if anyone
would like to help, they are certainly welcome. It just
makes more sense to have our code bundled with apache than
it does to continue maintaining a separate distribution.
4) apreq-2 is compact, and it makes good use of apr/apr-util.
It should require very little additional effort to add it to
the core other than bringing its API docs up to speed. A patch
against current httpd-2.0 cvs is at
http://httpd.apache.org/~joes/httpd-2.0.patch
5) The apreq-2 tests are already written: here's a patch for
httpd-test/perl-framework:
http://httpd.apache.org/~joes/httpd-test.patch
We'll try to address any concerns as they are raised.
Thanks.
[*] - Some background on (lib)apreq:
apreq is a safe, standards-compliant, high-performance library
used for parsing HTTP cookies, query-strings and POST data. The
current version apreq-1 is well tested and widely deployed. It
was designed and originally implemented by Lincoln Stein and Doug
MacEachern over four years ago, and has seen many improvements since
then. apreq was placed under the ASF umbrella in December 2000.
The 2.0 version of apreq is an improved version that's been
ported to run on httpd-2.0. Here's a brief list of features
it has that apreq-1 does not:
* provides overridable parsers for "application/x-www-form-urlencoded",
"multipart/form-data", and in the future "text/xml" enctypes.
* accepts chunked POST data.
* Support for RFC-based Cookies.
* XForms will be supported.
Re: Adding apreq-2 to httpd-2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:01 AM 8/21/2002, rbb@apache.org wrote:
>On 21 Aug 2002, Jeff Trawick wrote:
>
> > Joe Schaefer <jo...@sunstarsys.com> writes:
> >
> > > The apreq developers would like to see apreq-2 [*]
> > > make its way into the apache 2 distribution. Here's why:
> >
> > Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> > interested in what other people think)
>
>I would think that this would be a better match for apr-serf.
For the generic functionality [e.g. breaking apart cookies, various RFC
style entities, etc.] it would make sense in either apr-serf or apr-util.
Only the server-specific processing [e.g. POST request dispatching]
needs to go in httpd-2.0/modules/http. Client-like functionality from
both apreq and proxy should starting moving into apr-serf.
Bill
Re: Adding apreq-2 to httpd-2.0
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
> [...]
>
>
>>Here's an odd idea Stas and I kicked around... why not port apreq2.0
>>into a filter? This is the idea;
>>
>>Folks writing a body-consuming -filter- could call the prepare fn to
>>inject the apreq filter into the input chain. If more than one filter was
>>interested, it would still inject itself only once.
>>
>>Now, as the input body is read, it would make the POST info available
>>to any and every filter plus the handler module.
>>
>>The advantage? Because it's a filter, the actual POST body is still
>>available to a CGI or other non-apreq application to consume ;-)
>
>
> I think that's the ideal approach, assuming the notion of
> "body-consuming filter" includes content-handlers (and also
> that output filters could get at the apreq-parsed input data
> if it was available). It'd be great if apreq-2 users didn't
> need to pass the parsed data around via pnotes (that's what they
> do in 1.0).
>
> Pragmatically speaking, the filter API is completely foreign to me,
> and I'm sure it would enforce some additional discipline on how
> we handle the buffering of POST data. It'd be really nice if one
> of the resident experts were willing to lend an ear to the apreq-dev
> list. We can't keep bothering Stas, well at least not *just* Stas :-)
Converting httpd-apreq-2 into an input filter is a relatively easy thing
to do, especially since we don't change the data that goes through the
filter. Just look at any of the input filters (e.g. mod_deflate), and
copy the skeleton. the rest is relatively simple, the only thing I'm not
sure about is where to store the parsed data, connection pool's user data?
I'm planning to go on a long vacation soon and have a heap of things to
finish before I leave. If I complete them all in time. I'll definitely
do the porting. But count on my assistance if you have any
questions/problems.
In any case I think we should first have a consensus on what happens to
apreq before investing any more time into the porting.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Adding apreq-2 to httpd-2.0
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
[...]
> Here's an odd idea Stas and I kicked around... why not port apreq2.0
> into a filter? This is the idea;
>
> Folks writing a body-consuming -filter- could call the prepare fn to
> inject the apreq filter into the input chain. If more than one filter was
> interested, it would still inject itself only once.
>
> Now, as the input body is read, it would make the POST info available
> to any and every filter plus the handler module.
>
> The advantage? Because it's a filter, the actual POST body is still
> available to a CGI or other non-apreq application to consume ;-)
I think that's the ideal approach, assuming the notion of
"body-consuming filter" includes content-handlers (and also
that output filters could get at the apreq-parsed input data
if it was available). It'd be great if apreq-2 users didn't
need to pass the parsed data around via pnotes (that's what they
do in 1.0).
Pragmatically speaking, the filter API is completely foreign to me,
and I'm sure it would enforce some additional discipline on how
we handle the buffering of POST data. It'd be really nice if one
of the resident experts were willing to lend an ear to the apreq-dev
list. We can't keep bothering Stas, well at least not *just* Stas :-)
> > > I wouldn't want to see it added to httpd-2.0 or apr-util unless the
> > > non-API helper macros are removed from the public header file.
> >
> >Good idea.
>
> or, they are considered worthwhile enough for httpd itself [or a good
> minority of modules.] We have too many helpers/ways of doing things
> right now with the mod_ssl'ish plus the other one-off helpers in other
> modules. If I had time [loud booming sinister laughter here] it would
> be fun to reap all of the module helpers into a single header and start
> to standardize them.
Heh, feel free to swipe/rework everything in apreq.[ch]; that stuff is
only there because I couldn't find an appropriate ap(r) replacement
(apreq_getword will probably we bagged in any event; it's misnamed, and
I think we can do without it). I'd rather not have an apreq.c file at
all :-)
--
Joe Schaefer
Re: Adding apreq-2 to httpd-2.0
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> > > I wouldn't want to see it added to httpd-2.0 or apr-util unless the
> > > non-API helper macros are removed from the public header file.
> >
> >Good idea.
>
> or, they are considered worthwhile enough for httpd itself [or a good
> minority of modules.] We have too many helpers/ways of doing things
> right now with the mod_ssl'ish plus the other one-off helpers in other
> modules. If I had time [loud booming sinister laughter here] it would
> be fun to reap all of the module helpers into a single header and start
> to standardize them.
the helpers I see in apreq shouldn't be let out of the closet :)
does C really need unless and until? is memEQ so much better than
!memcmp that we need to learn a new API?
all in fun,
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Adding apreq-2 to httpd-2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:53 AM 8/21/2002, Joe Schaefer wrote:
>Jeff Trawick <tr...@attglobal.net> writes:
>
> > Joe Schaefer <jo...@sunstarsys.com> writes:
> >
> > > The apreq developers would like to see apreq-2 [*]
> > > make its way into the apache 2 distribution. Here's why:
> >
> > Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> > interested in what other people think)
>
>apreq makes a lot of use of request_rec; my impression of
>the apr and apr-util projects seemed to suggest that was a
>no-no.
Yes, it isn't a fit into apr-util.
Here's an odd idea Stas and I kicked around... why not port apreq2.0
into a filter? This is the idea;
Folks writing a body-consuming -filter- could call the prepare fn to
inject the apreq filter into the input chain. If more than one filter was
interested, it would still inject itself only once.
Now, as the input body is read, it would make the POST info available
to any and every filter plus the handler module.
The advantage? Because it's a filter, the actual POST body is still
available to a CGI or other non-apreq application to consume ;-)
> > I wouldn't want to see it added to httpd-2.0 or apr-util unless the
> > non-API helper macros are removed from the public header file.
>
>Good idea.
or, they are considered worthwhile enough for httpd itself [or a good
minority of modules.] We have too many helpers/ways of doing things
right now with the mod_ssl'ish plus the other one-off helpers in other
modules. If I had time [loud booming sinister laughter here] it would
be fun to reap all of the module helpers into a single header and start
to standardize them.
Bill
Re: Adding apreq-2 to httpd-2.0
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Jeff Trawick <tr...@attglobal.net> writes:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
> > The apreq developers would like to see apreq-2 [*]
> > make its way into the apache 2 distribution. Here's why:
>
> Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> interested in what other people think)
apreq makes a lot of use of request_rec; my impression of
the apr and apr-util projects seemed to suggest that was a
no-no.
> I wouldn't want to see it added to httpd-2.0 or apr-util unless the
> non-API helper macros are removed from the public header file.
Good idea.
--
Joe Schaefer
Re: Adding apreq-2 to httpd-2.0
Posted by Thom May <th...@planetarytramp.net>.
* Jeff Trawick (trawick@attglobal.net) wrote :
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
> > The apreq developers would like to see apreq-2 [*]
> > make its way into the apache 2 distribution. Here's why:
>
> Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> interested in what other people think)
>
I think that's actually the best fit we have at the moment. I guess -util
becoming a server-side lib would nicely balance with -serf being a client
side lib.
> I wouldn't want to see it added to httpd-2.0 or apr-util unless the
> non-API helper macros are removed from the public header file.
>
*nod*
-Thom
--
Thom May -> thom@planetarytramp.net
<Overfiend> Lords and squires,
<Overfiend> Were you aware of the fact that you could increaseth the size of
your penis by as much as half a cubit? Come visit the apothecary
and essay the new miracle tonic by Dr. Goodfellow! You'll have
all the fair maidens screaming, 'Good Knight!'
Re: Adding apreq-2 to httpd-2.0
Posted by rb...@apache.org.
On 21 Aug 2002, Jeff Trawick wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
> > The apreq developers would like to see apreq-2 [*]
> > make its way into the apache 2 distribution. Here's why:
>
> Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> interested in what other people think)
I would think that this would be a better match for apr-serf.
Ryan
Re: Adding apreq-2 to httpd-2.0
Posted by Jeff Trawick <tr...@attglobal.net>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> The apreq developers would like to see apreq-2 [*]
> make its way into the apache 2 distribution. Here's why:
Did you consider adding it to apr-util? (probably a dumb idea, but I'm
interested in what other people think)
I wouldn't want to see it added to httpd-2.0 or apr-util unless the
non-API helper macros are removed from the public header file.
(examples)
+#ifndef strncaseEQ
+#define strncaseEQ(s1,s2,n) (!strncasecmp(s1,s2,n))
+#endif
+
+#ifndef unless
+#define unless(Q) if(!(Q))
+#endif
Also, it would be nice if some Apache modules in httpd-2.0 are changed
to use it in the short term.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...