On Thu, Feb 2, 2017 at 5:16 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Thu, Feb 2, 2017 at 4:51 PM, Luca Toscano <toscano.l...@gmail.com> wrote: >> >> 2017-01-30 21:58 GMT+01:00 Yann Ylavic <ylavic....@gmail.com>: >>> >>> Maybe what is missing is nonblocking reads on the backend side, and on >>> EAGAIN flush on the client side to detect potential socket errors? >> >> Interesting.. So the idea would be to be non blocking while reading from the >> FCGI backend, and in case of EAGAIN flush to the client in order to force >> ap_pass_brigade to detect if the client aborted the connection. > > Yes, poll() => POLLIN => read() while data available => EAGAIN => > flush => poll().
The "read() while data available => EAGAIN" may be replaced by "read() while read buffer is full" so to avoid a (likely) useless last non-blocking read. > > The flush is necessary because output filters down the road might have > buffered, so it makes so that everything so far reaches the socket > (with potential error). > >> The flushing >> part might be tricky to implement (at least for me, but I'll try to work on >> it :). > > It should be as easy as pushing a FLUSH bucket at the end of the > brigade passed to the client ;) > > The hard part may be more the non-blocking read (and handling of > incomplete headers/data). > > Regards, > Yann.
