Plugin proxy: Stream the response

[adamziel]

plugin-proxy.php currently buffers the entire zip artifact downloaded from GitHub. This means the browser can only start downloading, say, a WordPress core build from a specific PR once the PHP script has the full response. This significantly slows down the WordPress PR previewer. Let's make sure the plugin-proxy.php streams the response body as it receives the bytes.

[dmsnell]

For some nginx configurations I had to add the following header to prevent it from buffering the PHP response.

X-Accel-Buffering: no

Note also that it's important to close any outstanding output buffers. This may break things if done with disregard, but here in the proxy we should have enough oversight to do it safely.

set_time_limit( 0 );
ob_implicit_flush( 1 );
while ( ob_end_flush() ) {
	continue;
}

[adamziel]

This was resolved in #889 which uses CURL CURLOPT_WRITEFUNCTION with flush(); for streaming. It seems to be working pretty well, but I wonder if adding this bit just to be safe would still be a good idea:

set_time_limit( 0 );
ob_implicit_flush( 1 );
while ( ob_end_flush() ) {
	continue;
}

Note that ob_start() is never called.

[dmsnell]

Note that ob_start() is never called.

In WordPress it's important to run this loop because a plugin may have called ob_start(), or the code is complicated enough that it may be hard to track down places it was called. This is safe to call even when ob_start() has never been called.

in #889 which uses CURL CURLOPT_WRITEFUNCTION with flush();

As long as it's working then it's good, but to point it out, my comment was about nginx which operates above the level of PHP. It's possible that in some environments the curl functionality will be buffered because of the frontend web server, which wraps the responses.