httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [rfc] some thoughts for apreq-2
Date Fri, 03 Jan 2003 16:48:45 GMT

[cc'd discussion to apreq-dev list]

Eli Marmor <> writes:

> The main idea is to use the filtering mechanism to its limits, so apreq
> can:
> 1. be used by modules from most of the layers (except for, obviously,
>    the CONNECTION layer - i.e. SSL and gzip...)

Right- the idea is to make the parsed data available to the
request (input and output) filters, as well as the content 
handler itself.

> 2. change values and not only read them (maybe the following is
>    possible: when an input filter is pushing the bucket-brigades to the
>    following filter, after it modified the apreq tables, the POST data
>    (or the GET after the "?") will be rewritten to reflect the new
>    values.

You can do that already, but it's

  1) cumbersome, since apache tables aren't designed for fast deletes.

  2) IMO not a good idea, since it amounts to lying to *other* apps 
     about the actual client data.  In very rare cases (e.g. a broken
     browser) it might be necessary to do that, but I can't think of
     a good reason why apreq users should *want* to modify table entries.
     The same thing goes for incoming cookies.

> 3. be separated into two layers, one of them independent of Apache (but
>    only depends on APR). It allows external programs (such as CGI's and
>    FastCGI) to use it. 

I think it's possible to embed a home-brewed "request_rec" into an 
application, that basically tricks libapreq into thinking it is running 
inside httpd.  With apreq-2, there'd be a bit more work to do that since 
httpd's filter API would need emulation also.  It's not something that
interests me personally, but if you'd like to see this happen, I'm
not opposed to it either.

Some portions of apreq-2 could go into APR, but apreq is very much
tied to HTTP.  After looking over my current code, I don't expect 
the "generically useful for APR*" portion to amount to very much.


Barring unforeseen events :-), I'd like to put up an apreq-2 
repository on in the next few days.  A functional 
filter implementation isn't far off now; IOW I expect the C API to 
be reasonably polished by the end of January.  

Assuming we're all basically satisfied with it by then, we can lock 
down the core API at the end of this month, and let the application 
programmers (especially the language-gluers) do their thing with 

Joe Schaefer

View raw message