"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 :-) > > > 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
