Glenn Strauss <[EMAIL PROTECTED]> writes: > 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?
"Bottom" being r->input_filters, why not? > > > 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 Currently HTTP_IN isn't even on the filter stack when ap_get_mime_headers is invoked; only connection filters are in play at that point, no? If you want to see an example of how this is be implemented one level up, at the request-filter/protocol filter boundary, take a look at mod_apreq in httpd-apreq-2 current cvs. -- Joe Schaefer
