Glenn Strauss <[EMAIL PROTECTED]> 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 AP_MODE_READBYTES. > That's what I'm trying to accomplish, too. Agreed. > > 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
