Enables the CURL PHP extension on playground.wordpress.net when networking is enabled. This is made possible by the TLS 1.2 implementation merged in #1926.
This PR:
Enables the curl extension
Rebuilds PHP.wasm for the web
Enables curl_exec and curl_multiexec functions in web browsers
Strips the response content-length and switches to Transfer-Encoding: Chunked
Unrelated – adds a JSPI vs Asyncify indication to the SAPI name so that we can easily learn which PHP.wasm build Playground is running
Related to #85
Closes #1008
Why use Transfer-Encoding: chunked?
Web servers often respond with a combination of Content-Length
and Content-Encoding. For example, a 16kb text file may be compressed
to 4kb with gzip and served with a Content-Encoding of gzip and a
Content-Length of 4KB.
The web browser, however, exposes neither the Content-Encoding header
nor the gzipped data stream. All we have access to is the original
Content-Length value of the gzipped file and a decompressed data stream.
If we just pass that along to the PHP-side request handler, it would
see a 16KB body stream with a Content-Length of 4KB. It would then
truncate the body stream at 4KB and discard the rest of the data.
This is not what we want.
To correct that behavior, we're stripping the Content-Length entirely.
We do that for every single response because we don't have any way
of knowing whether any Content-Encoding was used. Furthermore, we can't
just calculate the correct Content-Length value without consuming the
entire content stream – and we want to pass each data chunk to PHP
as we receive it.
Instead of a fixed Content-Length, this PR uses Content-Encoding: Chunked,
and then provides a per-chunk Content-Length.
Testing instrucions
Confirm the new E2E tests are sound and that they work in CI. You could also try installing a CURL-reliant plugin such as Plausible and confirm it installs without the fatal errors reported in #1008
Enables the CURL PHP extension on playground.wordpress.net when networking is enabled. This is made possible by the TLS 1.2 implementation merged in #1926.
This PR:
Related to #85 Closes #1008
Why use Transfer-Encoding: chunked?
Web servers often respond with a combination of Content-Length and Content-Encoding. For example, a 16kb text file may be compressed to 4kb with gzip and served with a Content-Encoding of
gzip
and a Content-Length of 4KB.The web browser, however, exposes neither the Content-Encoding header nor the gzipped data stream. All we have access to is the original Content-Length value of the gzipped file and a decompressed data stream.
If we just pass that along to the PHP-side request handler, it would see a 16KB body stream with a Content-Length of 4KB. It would then truncate the body stream at 4KB and discard the rest of the data.
This is not what we want.
To correct that behavior, we're stripping the Content-Length entirely. We do that for every single response because we don't have any way of knowing whether any Content-Encoding was used. Furthermore, we can't just calculate the correct Content-Length value without consuming the entire content stream – and we want to pass each data chunk to PHP as we receive it.
Instead of a fixed Content-Length, this PR uses Content-Encoding: Chunked, and then provides a per-chunk Content-Length.
Testing instrucions
Confirm the new E2E tests are sound and that they work in CI. You could also try installing a CURL-reliant plugin such as Plausible and confirm it installs without the fatal errors reported in #1008