https://bz.apache.org/bugzilla/show_bug.cgi?id=56188
--- Comment #25 from Luca Toscano <toscano.l...@gmail.com> --- >From a discussion in dev@ about polling the client's TCP connection: """ It could be achievable, but not easy, with care taken to pull the client's socket out of the pollset if anything but an error or a connection/TLS close is detected. It probably also shouldn't start before "last_stdin" is true. Client side poll() may return with either: 1. HTTP data (pipelined) => client still alive, non-empty/meta brigade => don't abort 2. TCP close or reset => bucket EOS or an APR_E* (though speculative-non-blocking reads won't return EOS, and may turn EOF into SUCCESS with empty brigade!) => abort 3. TLS close notify => EOS/EOF? => abort 4. TLS renegotiation => rejected by httpd (since initiated by the client) => an APR_E* => abort n. ... Probably not an exhaustive list... """ So even if the patch provided by Jason works and looks good, it might introduce some weird corner cases for the general consumption that might create regressions during the next release. This doesn't mean that the patch can't work for specific use cases, but it might not be the best one for all of them. Another approach that was proposed by Yann is the following: use non blocking recv while reading from the FCGI backend, and in case of EAGAIN send a FLUSH bucket to the client in order to force ap_pass_brigade to detect if the client aborted the connection. poll() => POLLIN => read() while data available => EAGAIN => flush => poll() Remark: 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. Remark 2: https://httpd.apache.org/docs/2.4/developer/output-filters.html#basics """ FLUSH buckets are sent when the content generator (or an upstream filter) knows that there may be a delay before more content can be sent. By passing FLUSH buckets down the filter chain immediately, filters ensure that the client is not kept waiting for pending data longer than necessary. Filters can create FLUSH buckets and pass these down the filter chain if desired. Generating FLUSH buckets unnecessarily, or too frequently, can harm network utilisation since it may force large numbers of small packets to be sent, rather than a small number of larger packets. """ -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
