httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: dev question: apreq 2 as a filter?
Date Tue, 27 Aug 2002 03:25:42 GMT
Joe Schaefer wrote:
> "William A. Rowe, Jr." <> writes:
>>At 11:18 AM 8/26/2002, Joe Schaefer wrote:
> [...]
>>>For instance, it would be a bad thing if the content-handler injects
>>>apreq at the end of the filter chain, then "does something" to cause
>>>apreq to prefetch some post DATA, and *then* wants to inject utf-8
>>>somewhere upstream from the apreq filter.
>>That's easy... when you insert a filter, you can choose to insert it before
>>or after another filter.  Any filter that wants apreq results before processing
>>it's own input filtering MUST insert itself behind the apreq filter, after 
>>the fn to inject and initialize the apreq filter.
> That's not the case I'm worried about.  I'm worried about the case
> where the to-be-inserted filter wants to modify the input stream 
> *before* apreq starts parsing it.  The to-be-inserted filter isn't
> interested in the apreq data whatsoever.
> For example, someone may write a filter whose job is to run a SAX-ish
> XSL transform on the incoming "text/xml" data.  (Perhaps even as a fixup
> for apreq's xml parser).  We had better not have prefetched any of the 
> POST before that filter is injected upstream.

If the apreq filter copies the data it reads elsewhere, without changing 
anything passing through it, any other filters coming after it should be 
just fine, no?

In data => filterA => filterAPREQ => filter B => content handler =>
                            \                        /

If that's correct, apreq filter should be placed on the list of filters, 
*after* filters that convert network packed/encoded data into normal 
data (ssl, deflate filters), but *before* any special purpose filters 
(.e.g. XSL transform filters, utf8, etc) because the content handler 
wants the body as it was sent by the client, without making any 
transformations on it.

Therefore it should be possible to insert special purpose filters after 
the apreq filter, which may mangle the original body, but this shouldn't 
affect the body seen by apreq and any content handler calls to apreq_*().

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message