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 Wed, 28 Aug 2002 02:48:54 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>Joe Schaefer wrote:
> [...]
>>>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 =>
>>                            \                        /
>>                             -->--->------------->---
> Right.  But imagine that the content handler injects filterA at runtime, 
> *after* filterAPREQ has prefetched some data. (In my example, filterA 
> was the XSL transformer).  This is clearly an error, but by whom?
> Two specific questions:
>   1) How would this error condition be communicated to the content
>      handler?  Would filterA's injection call be responsible for 
>      reporting it?
>   2) Is this error condition predictable, in the sense that the 
>      content-handler knows when filterAPREQ might prefetch some
>      data?
> I'm guessing the answer to these questions is yes, and question
> (2)'s answer might be along the lines of:  
>   IO by the content handler, in *either* direction, may cause 
>   apreq to prefetch data. Until then, it should be safe to modify 
>   the input filters.
> But I'm not sure, so I'd like to know what others think.

I suppose we are going to hear about similar problems with different 
other filters, it's getting harder to make things play nice with each other.

The only way to arbiter the insertion of the filters is to specify the 
filter names after and before which ones your filter should go in. 
Meaning that we might be forced to provide configuration directives 
which make things flexible and configurable by the end user.

>>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), 
> Yes...
>>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.
> This may not always be possible/desirable.  A perfect example is
> the botched empty-file-upload bug of 0.9.7 (it's missing a CRLF
> in any empty file upload block.)  Instead of writing a special-case 
> parser to deal with this, (or worse, allow our mfd parser to work around 
> it) it's far better to have an upstream filter just restore the 
> missing CRLFs.

that's a bit different. The filter you are talking about is part of the 
apreq bundle, so apreq can easily decide what's right for it and insert 
this filter before the main consuming apreq filter. I still think of it 
as a single filter, even though it could be that it's better to have a 
special filter in front. Though be careful here, adding too many filters 
will hurt performance. If it's possible to merge some filters, it'll 
probably make things faster.

But I was talking about *other* special purpose filters, which weren't 
designed to play nice with apreq.

Here is the adjusted data flow diagram:

=> filterA => APREQ filter(s)=> filter B => content handler = > 

                     \                        /

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

View raw message