httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: RFE: ap_input_mode_t as bitflags
Date Fri, 13 Aug 2004 18:36:38 GMT
Glenn Strauss <> writes:


> > I really don't like the very confusing AP_MODE_* semantics
> Would they be less confusing if the behavior was more consistent?

No, because of the burden these modes place other filters (eg
mod_deflate).  Downstream input-filters / content-handlers cannot 
rely on upsteam filters doing anything sane with modes other than 

> 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.

Then IMO those protocols need a protocol filter which implements
without extending their protocol's specific needs into the
upstream filters.

> If you are suggesting that there be no line-mode to read from filters,

I am.

> 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.  

If a protocol filter reads more data than it needs, then that filter
needs to set-aside the excess data for downstream filters to collect.
I see no reason why an imput filter needs to push the excess data 
back upstream.

Joe Schaefer

View raw message