On 07/18/2017 01:38 AM, Luca Toscano wrote:
I didn't do it on purpose because I didn't want to mess with the main apr_poll, but if you find an elegant solution I am all for it.
It'll take some work, but I think it's doable.
My understanding is that in this case we don't need to listen to POLLOUT events since we are focusing on flushing (giving priority to it), and then we'll pay attention to POLLOUT when the main apr_poll will happen.
There's nothing semantically wrong with doing that, but I think it can lead to some hard-to-debug performance issues in certain cases. Especially if outgoing chunks from the application are blocked waiting on incoming chunks for the client. There are some more issues that came up while I was playing around with the architecture: - Reads from the request body brigade are blocking, which leads to a common pattern: the backend has written data that is ready to be sent to the client, but it's not going anywhere because we are waiting for the client to send something. - If the backend sends FCGI_END_REQUEST without closing its stdout stream, we don't seem to correctly end the response with a zero-length chunk. I have not investigated this fully yet, but maybe it has something to do with not correctly sending an EOS bucket? - For scripts that are not running in NPH mode, we're required by the CGI spec to strip any incoming transfer-codings and present a final Content-Length to the application. Omitting CONTENT_LENGTH is supposed to mean that there is no request body. But for incoming chunked transfers, we just pass the chunks on to the backend without a CONTENT_LENGTH, which appears to confuse e.g. PHP-FPM. Jim pointed out that mod_proxy already has the concept of request body spooling, so we should probably make use of it. --Jacob
