On Fri, Aug 13, 2004 at 12:37:30PM -0400, Joe Schaefer wrote: > Justin Erenkrantz <[EMAIL PROTECTED]> 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. Cheers, Glenn
