httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: mod_proxy_fcgi and flush
Date Wed, 19 Jul 2017 22:33:18 GMT
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.


View raw message