httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 14 Nov 2000 15:52:51 GMT

> > > Personally, I want to see this filter removed completely, but if it is
> > > going to go into the server, it should be a universal thing.
> >
> > Yes, I agree. I don't see a need to keep it around after the ap_r* work is
done.  In the meantime,
> > it does tame mod_auto_index.   It'll be out in a week, perhaps sooner.
> How do you plan to improve ap_r*?  The only possible way to do that, is to
> have copy the data into a heap bucket in the ap_r* functions.  Then you
> have to find a place to store the buffer, which can only go in the
> request_rec.  I have toyed with this idea since the buckets were
> originally designed, and I really dislike it.  This relies on all of the
> ap_r* functions working together to ensure that this works at all.
> I really think that the proper way to solve this problem is to re-write
> handlers if you want optimal performance, and ignore the handlers that are
> still written to the old API.  The handlers will still work, but they
> won't be optimal.  The autoindex problem is being solved by OtherBill
> right now.  Chunking is not an issue if the handler is sane in creating
> blocks of data.
> Again, not a vote and not a veto, just an opinion.

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.


View raw message