Chuck Murcko <[EMAIL PROTECTED]> writes:
> On Wednesday, July 18, 2001, at 03:49 PM, Jeff Trawick wrote:
> >
> Kind of, but the comment
>
> /* ### woah... ap_http_filter() is doing this, too */
>
> from ap_dechunk_filter() gives me pause that the problem is bigger
> than one filter.
> Is general input filter policy to strip eos buckets and append its
> own? Or does this vary by filter? I'm wondering how to know when I'm
> done ap_get_brigade'ing. Checking for eos is apparently not the
> correct answer. Just wondering if it should be.
The issue with the removing and adding an eos bucket on this path is
based on the fact that the dechunk filter doesn't read ths chunk
header/trailer via a filter/brigade interface. It reads it via
ap_getline(), which has no way to send back an eos bucket.
So ap_http_filter() adds the eos bucket, which is needed by
ap_getline(). ap_getline() doesn't return a brigade to its caller so
it is lost. dechunk filter needs to return a brigade to its caller so
it is added back.
Sucky? Perhaps... Unfortunate? Definitely...
How can ap_getline() continue to make life simple for its callers and
yet avoid get bogosity associated with the eos bucket?
Perhaps it should return a "normalized" brigade, where the line is
guaranteed to be contained in the first bucket and there may or may
not be a subsequent eos bucket?
Perhaps it should return the optional eos bucket via a separate
parameter so that the same one can be returned by ap_getline()? (One
problem with this is that not all callers are filters so extra logic
would be needed in places to dispose of the eos bucket.)
If we get our bucket performance in order then it shouldn't matter
anyway, and life for the callers of ap_getline() can continue to be
very simple.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
