Joe Schaefer wrote: > "William A. Rowe, Jr." <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
