Mailing List Archive

What is apreq?
Lately lots of different httpd folks are asking me
questions about apreq, and from that feedback this
post seems to be needed to clarify what apreq's design
and goals are all about.

Simply put, apreq implements the HTML form specs on
the server side.  The name itself was coined by Lincoln
Stein and Doug Maceachern mainly aimed at addressing
a deficiency in the request_rec struct- namely that it
doesn't do any processing of query strings and POST data.
The original perl package was called Apache::Request
and that's where the apreq monkier comes from- it is
NOT a client-side HTTP request library like neon or serf-
totally unrelated technologies to apreq.

There are two distinct parts to apreq's current implementation-
the library, libapreq2, and the httpd filter module mod_apreq2.

libapreq2 (which is the stuff currently sitting in trunk/server)
depends entirely on libapr and libaprutil- there are no httpd-specific
parts involved in it.  Actual end users of libapreq2 go through
the apreq module API, and libapreq2 provides both a CGI/FCGI
module, and a "feed the parser yourself" generic module, but
people who want to write httpd modules need mod_apreq2 which
is both an httpd module and an apreq module- the two files
comprising the implementation of mod_apreq2 reflect this division.

The reason apreq has a module api at all is because we wanted
to make available to C programmers a HTML form processing lib
that will essentially remain source-compatible within any implementation
context at all, be it CGI, FCGI, or httpd.  This is something
most dynamic languages that hook into httpd provide essentially
for free, but with apreq it becomes feasible to provide that
functionality to C programmers as well.  The only apreq-based
source changes that are specific to the programming environment
are the selection and instantiation of an appropriate handler
based on whatever module you need to use for that environment-
something easily dealt with using #ifdefs.  Unfortunately this
aspect will be lost unless libapreq2 continues to be made available
as a separate object from httpd itself.

I've personally scrutinized virtually every line in apreq's sources
several times over now, so I'm fairly confident enough in it to say
that the implementation is safe to use and will perform as well or
better than any similar tech out there (when used properly).  That's
not to claim there are no outstanding security issues within the code,
just that nothing obviously exploitable/dosable stands out on a cursory
source scan.  And apreq minimizes strcpy-like operations, preferring
zero-copy algos as much as is feasible.  It also supports HTTP chunked
POST requests which is a novel feature for this sort of thing, no other
lib that I've looked at does that.

Anyway that's a brief overview of apreq, if people have followup questions
I'd be happy to address them.

Re: What is apreq? [ In reply to ]
On 28.04.2012 09:05, Joe Schaefer wrote:
> libapreq2 (which is the stuff currently sitting in trunk/server)
> depends entirely on libapr and libaprutil- there are no httpd-specific
> parts involved in it.
To me this suggests, it may be generally useful and thus should have a
life of its own -- outside of httpd source -- thus allowing other
projects to begin using it as a 3rd-party library, that can be listed as
a project's dependency.

Myself a porter of quite a few 3rd-party packages to my OS of choice
(FreeBSD), I have a deep resentment towards software projects, which
bundle multiple projects' code in their own sources. OpenOffice is the
worst offender by far in this regard, bundling not only all of /its own/
code together, but also including (and fully recompiling as part of the
build) the full sources of python, boost, libjpeg, expat, png, zlib,
epm, and a bunch of other projects... Had it not been for licensing
reasons, I'm pretty sure, they would've been bundling Java as well...

It is very rare (if ever), that such bundling is justified -- most of
the time it is done for reasons like:

* "We wish to provide complete build tree that can be built independently"
* "We don't want to support interactions with other versions of the
library, which you might have"

Neither reason is valid, in my not so humble opinion:

* The first reason leads to pessimizing well-managed computer systems
(using well-manageable OSes), where recent versions of all
dependencies are already independently available, for the benefit of
the poorly-managed ones.
* The second is completely superfluous, because no "support" is
promised neither implicitly nor explicitly anyway.

So, in the same opinion, not just libapreq (if it is, indeed, generally
useful), but also apr and aprutil ought to be available /only/ as
standalone packages and used as such during build by default.