On 19 Nov 2013, at 7:44 PM, Graham Leggett <minf...@sharp.fm> wrote: > This is indeed broken, fixed. > > Some more testing has revealed that mod_ssl's output filter breaks rules 2 > and 5 of the 10 output filter rules published here: > http://httpd.apache.org/docs/trunk/da/developer/output-filters.html#rules > > Instead of passing on all metadata buckets as required, mod_ssl only takes > into account EOS, EOC and FLUSH, and tries to consume metadata buckets as > normal data buckets. SSL_write() then sees the zero length write and treats > it as a noop. The core filter is never called, the event mpm interprets a non > zero c->data_in_output_filters as an invitation to try again, and we go into > a spin. If mod_ssl does this, we can expect other modules in the wild to be a > problem. > > A possible solution to this dilemma is to try and detect buggy filters and > compensate for the problem. We might have a protocol helper filter that run > early on and passes the brigade upstream. If we started with > c->data_in_output_filters as non zero and we are in WRITE_COMPLETION, and on > return the filter sees APR_SUCCESS from upstream, but > c->data_in_output_filters is still not zero, we may not have reached the core > filter, so call the core filter directly once with a nonblock bucket > simulating the behaviour we have now. This will ensure the setaside data in > the core output filter will always be written at least once on each call, > preventing the spin. This path in theory should only be followed if the buggy > filter is present, because when the buggy filter is not present and the core > is successfully reached the return code will be APR_EAGAIN, or APR_SUCCESS > with c->data_in_output_filters going to zero.
Something like the attached patch, which was a lot simpler than the above. Regards, Graham --
httpd-core-nonblocking2.patch
Description: Binary data
