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