httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Strauss <gs-apache-...@gluelogic.com>
Subject Re: RFE: ap_input_mode_t as bitflags
Date Sat, 14 Aug 2004 01:04:42 GMT
On Fri, Aug 13, 2004 at 03:08:17PM -0400, Joe Schaefer wrote:
> Glenn Strauss <gs-apache-dev@gluelogic.com> writes:
> 
> [...]
> 
> > I'm not sure the answer to this one:
> > Are protocol filters attached to the request (I think so)
> > or to the connection?  If attached to the request, then 
> > wouldn't they need to push-back excess data before the request
> > finishes if the data is to be used by later requests on the
> > same connection?
> > 
> > The HTTP_IN filter allocates its ctx from r->pool, so it won't
> > survive multiple requests on the same connection.
> 
> I don't think HTTP_IN would normally read more than one 
> request at a time,

You suggested always using READBYTES.  If a POST used chunked T-E to
send input, then when HTTP_IN is reading chunk trailers, too much data
might be read, i.e. the next request line might be read.  What should
ap_get_mime_headers() do with the excess data at that point?  Should
it arbitrarily push an ephemeral filter onto the bottom of the
connection stack?

> but if it did, it could add an
> ephemeral connection filter and put the excess brigade
> in there.

Messy.  That makes the assumption that the connection-level
filters are right above HTTP_IN; that f->next is a connection-level
filter.  Otherwise, what about other protocol filters which might
be doing translation?  You're bypassing them and throwing data
above them at the connection level.  I don't think this occurs in
current practice, but it is still a violation of what is intended
for filtering, unless you're going to require that there only be
a single protocol filter, or that HTTP_IN always be at the top of
the protocol filter stack.


This just occurred to me: why not promote HTTP_IN to be a
connection level filter, and add a buffer brigade to http_ctx_t?
Not only would that handle the case above, but it would also
obviate the need for the ugly AP_MODE_EATCRLF because the
HTTP_IN filter would handle what is now done in check_pipeline_flush().

And if we remove folding ability from ap_rgetline_core(), (and
replace the one usage of folding in proxy_util.c), then we can
also get rid of AP_MODE_SPECULATIVE.

Getting rid of AP_MODE_SPECULATIVE and AP_MODE_EATCRLF sounds to me
like moves in the right direction.  What do you think?

Cheers,
Glenn


Mime
View raw message