On Fri, Aug 13, 2004 at 03:08:17PM -0400, Joe Schaefer wrote: > Glenn Strauss <[EMAIL PROTECTED]> writes: > > [...] > > > I'm not sure the answer to this one: > > Are protocol filters attached to the request (I think so) > > or to the connection? If attached to the request, then > > wouldn't they need to push-back excess data before the request > > finishes if the data is to be used by later requests on the > > same connection? > > > > The HTTP_IN filter allocates its ctx from r->pool, so it won't > > survive multiple requests on the same connection. > > I don't think HTTP_IN would normally read more than one > request at a time,
You suggested always using READBYTES. If a POST used chunked T-E to send input, then when HTTP_IN is reading chunk trailers, too much data might be read, i.e. the next request line might be read. What should ap_get_mime_headers() do with the excess data at that point? Should it arbitrarily push an ephemeral filter onto the bottom of the connection stack? > but if it did, it could add an > ephemeral connection filter and put the excess brigade > in there. Messy. That makes the assumption that the connection-level filters are right above HTTP_IN; that f->next is a connection-level filter. Otherwise, what about other protocol filters which might be doing translation? You're bypassing them and throwing data above them at the connection level. I don't think this occurs in current practice, but it is still a violation of what is intended for filtering, unless you're going to require that there only be a single protocol filter, or that HTTP_IN always be at the top of the protocol filter stack. This just occurred to me: why not promote HTTP_IN to be a connection level filter, and add a buffer brigade to http_ctx_t? Not only would that handle the case above, but it would also obviate the need for the ugly AP_MODE_EATCRLF because the HTTP_IN filter would handle what is now done in check_pipeline_flush(). And if we remove folding ability from ap_rgetline_core(), (and replace the one usage of folding in proxy_util.c), then we can also get rid of AP_MODE_SPECULATIVE. Getting rid of AP_MODE_SPECULATIVE and AP_MODE_EATCRLF sounds to me like moves in the right direction. What do you think? Cheers, Glenn
