Ok, I know what I was thinking. Check out tmp_bb in ap_read_request in protocol.c (unpatched version). We create tmp_bb, do read_request_line, ap_get_mime_headers then destroy tmp_bb. My patch does essentially the same thing. If there is a request body to read, whoeever needs to read it will create a new brigade. In this regard, my patch does not create any new bogosity. (and no, we do not throw away the first read).
No, it's not the same thing. One is: 'read the request line and headers using this temporary brigade,' the other is: 'read part of the input body into this brigade - oh, by the way, feel free to read the headers and status while you are at it, and, oh, don't feel that I require any data.'
As I've said before, the patch uses ap_get_brigade only as a way to drive the input filters before we are ready to read the body. To me, it indicates a strong disconnect with how the filters are designed. Filters are meant to be called asynchronously as needed (pulled), but the request parsing must happen synchronously and at a specific point in time.
I don't fully understand why the status and header parsing must belong in an input filter (hammer, meet balloon). I think the patch could be rewritten removing the context of an input filter and still see significant performance benefits. At the time the request is read, there should be no other input filters, so I don't believe there would be significant overhead to not being an input filter. -- justin
