httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Strauss <>
Subject Re: RFE: ap_input_mode_t as bitflags
Date Fri, 13 Aug 2004 17:31:57 GMT
On Fri, Aug 13, 2004 at 12:37:30PM -0400, Joe Schaefer wrote:
> Justin Erenkrantz <> writes:
> [...]
> > Therefore, folding might only be possible to do in ap_http_filter, but
> > it can't go down further as into core_input_filter (which is where we
> > now call apr_brigade_split_line). A new getline_folding filter right
> > in front of ap_http_filter would do the trick,
> I really don't like the very confusing AP_MODE_* semantics

Would they be less confusing if the behavior was more consistent?
That's what I'm trying to accomplish, too.

> as a fundamental component of the input filter API.  Why not just 
> replace ap_get_mime_headers_core with a "request_parser" filter 
> (or add this functionality to ap_http_filter) that parses both 
> the request line and the incoming headers?  If that were done, 
> there would be no need for an AP_MODE_GETLINE invocation (hence 
> no apr_brigade_split_line in core_input_filter).

The problem is that many protocols are based around line-by-line
or MIME headers delimited by a blank CRLF line.  And even when
not in filters, I find myself having to parse lines out of brigades.

If you are suggesting that there be no line-mode to read from filters,
then we might also need some sort of way to push excess data back up
the filter chain if we pulled it, parsed out lines, and decided that
we did not need all of it, e.g. pulling the next HTTP request line
into the HTTP_IN filter for the current request.  IFF the HTTP_IN
filter was right before the connection level filters, it could insert
a filter at the bottom of the connection filters and push back the
excess data.  However, I think this is more complicated and more fragile
than having an API -- such as the readahead API I proposed -- that
handles the AP_MODE_* semantics for filters that use it.


View raw message