httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Winstead <j...@trainedmonkey.com>
Subject Re: summary: issues for my filtering patch
Date Wed, 28 Jun 2000 16:07:39 GMT
On Jun 28, rbb@covalent.net wrote:
> The requirement is still valid IMHO.  The ability to modify a header based
> on data in the response is a big part of filtering.  
> 
> This requirement is just as valid for the content-length, which Greg has
> said will be implemented in a later patch.  My argument is that this can
> not be done as an add-on.  This must be done as part of the original
> patch, or the original patch is incomplete and not the correct patch.

It seemed like the approach for a time was that the content-length
would simply get stripped out. The later enhancement I see is then
allowing filters to say up-front "I won't screw up the content-length"
or "I'll be adding 300 bytes to content-length". Requiring
content-length to always be preserved would force buffering all of
the content, and is contrary to how content-length is handled even
today.

If a filter is going to need to possibly modify a header based on
content, I don't see any way that filter can avoid buffering the
data. Unless the filter simply passes a flag on to a lower level
that says "hey, here's the data to send, but don't send it until
I tell you its okay, because I'm going to be adding a header". But
all you've gained in that case is the ability for the later layers
to start processing the data instead of having to wait for the
layer that thinks it needs to see all of its input before it can
send on its output. (Which it will presumably do by sending all
the accumulated data at once, so each later layer gets called
once and doesn't have to do any buffering.)

But it also just seems like an optimization. Like I said, PHP
didn't have any sort of output buffering until the latest version,
and although there was some grousing from users, they generally
accepted the limitation of not being able to add headers after
non-header data had been sent.

Jim

Mime
View raw message