httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 14 Nov 2000 17:33:08 GMT
> > I gues the root of our disagreement is the desirability of maintaining the
> > ap_r* stream interface. If we maintain it (and I am in favor of
maintaining
> > it), we need to make sure it doesn't cause Apache to abuse the network
(even
> > if it is technically 'correct').  This is about being good internet
citizens.
> > Without the coalesce filter, mod_auto_index sends many, many small packets
> > (few 10's of bytes) over the network. Maybe mod_auto_index is an extreme
> > example, but other 3rd party modules may do the same thing.  If we
maintain
> > the ap_r* interface, we need to coalesce the byte stream it produces. If
we
> > are not willing to do this, then perhaps we should drop the ap_r*
interface.
> >
> > I think Victor is playing around with ap_r* modifications. Let's take a
look
> > at what he does and go from there.
>
> I agree we can't send hundreds of 10 byte packets to the network.  But the
> place to fix this is either in the core_output_filter, or in a VERY
> simple coalesce filter that always sits on top of the
> core_output_filter.  One of the problems I have with the coalesce filter
> is that it is three pages long and it punts on some cases that it
> shouldn't punt on.
>

The coalesce filter needs to sit right above the chunk filter, else we can
have pathological cases where the chunking protocol overhead is greater than
the payload being transferred.  In the mod_auto_index case for example, we
commonly have chunks that are 1 or 2 bytes long.   Perhaps this coalesce
function needs to be rolled into the chunk filter.  I am more interested in
the function than in defending a particular implementation.

Bill



Mime
View raw message