httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: dev question: apreq 2 as a filter?
Date Tue, 27 Aug 2002 12:55:48 GMT
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

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.

> 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.

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.

Joe Schaefer

View raw message