On Wed, Jan 18, 2017 at 2:43 PM, Graham Leggett <minf...@sharp.fm> wrote: > On 18 Jan 2017, at 3:38 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> That's a good overview... Yeah, it might be getter better, but it does >> seem that the nature of the bugs implies it's also getting more >> fragile. Could be, likely is, just my impression due to some weird >> things I've seen lately on some testing.
We could make no improvement in trunk (bugfixes only) and have better feeling, yet that's not how we'll make httpd-next... Let's fix the bugs or revert if things really prove catastrophic, right? > > Pipelining support as it stands is really ugly. > > There is a point that is reached where we need to ask the question > “is there more data available to read”, and if the answer is yes, we > need to follow the pipeline path. We answer the question “is there > more data available to read” by trying to read some data, and then in > turn by tying ourselves in ugly knots trying to “unread” that data so > the next request can work. Are we talking about ap_check_pipeline()? > > I want to fix this properly so we don’t read data, we just get an > answer “there is data to be read”. Not sure I get the nuance, but "there is *HTTP* data to be read" (like ap_check_pipeline() does) looks reasonable to me, unless we want something like a "TLS close notify" (or trailing CRLFs) start a new request processing which will fail (or block). Regards, Yann.
