On Sun, 2002-06-30 at 01:34, Justin Erenkrantz wrote:
> It'd have to be a connection-level filter to ensure that we don't > lose pipelined-requests since we read too much. But, since we are > a connection-level filter, that means you don't have access to > the request. So, you'd have to split it out into two filters: > > - One connection-level filter that will split on a CRLFCRLF and > stash the rest away for the next read on this connection. > - One request-level filter that will expect a CRLFCRLF-segmented > brigade and process the headers and then get out of the way. The second of these doesn't actually have to be a filter. If a connection-level filter can supply a brigade containing just the request, we can do the parsing within ap_read_request() (or ap_get_mime_headers(), depending on whether this brigade contains the first line of the request). > Still sounds like an AP_MODE_GETLINES to me. =) Yeah. I just don't like the idea of requiring more than one filter to implement AP_MODE_GETLINES, since the logic for parsing HTTP headers should be orthogonal to the work that most input filters do. Do we always have core_input_filter at the top of the input filter stack when we're in ap_read_request()? If so, we could implement AP_MODE_GETLINES in core_input_filter and let all the other input filters return ENOTIMPL for this case. --Brian
