Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: Request: php_curl.dll with dynamic libcurl linking |
|
| Author |
|
AzureTai
Joined: 19 Mar 2026
Posts: 1
Location: UK
|
 Posted: Thu 19 Mar '26 21:25 Post subject: Request: php_curl.dll with dynamic libcurl linking |
 |
|
Summary: Request: php_curl.dll with dynamic libcurl linking for HTTP/3 / QUIC
Hi everyone,
I am currently running Apache 2.4.66-260223 Win64 (VS18) (ApacheLounge) on Windows 10 Pro 22H2 (build 19045.7058), together with PHP 8.5.4 NTS x64 VS17.
PHP is not running as mod_php. It is running as php-cgi.exe behind mod_proxy_fcgi, with Apache proxying requests to 127.0.0.1:9000. The PHP FastCGI process is managed via NSSM.
The runtime is configured as a persistent FastCGI worker pool (using PHP_FCGI_CHILDREN and PHP_FCGI_MAX_REQUESTS), effectively simulating PHP-FPM-style behaviour on Windows (minus the native Linux dynamic child process spawning provided by PHP-FPM, which is not available on Windows, hence the need to simulate this behaviour).
I am trying to get PHP cURL working with the libcurl.dll (8.18.0) build provided with the ApacheLounge distribution, which includes HTTP/3 (QUIC) (ngtcp2/nghttp3), Brotli compression, and LibreSSL.
My goal is for PHP to use the same curl stack that is already working from the command line.
Technical issue:
The stock Windows php_curl.dll appears to be built against a bundled/static libcurl (or otherwise not resolving an external libcurl.dll at runtime), which prevents PHP from using the QUIC-capable libcurl build already provided in the ApacheLounge toolchain.
Because this libcurl setup depends on a specific runtime chain (LibreSSL + ngtcp2 + nghttp3 + Brotli), I need a php_curl.dll that dynamically links against an external libcurl.dll, so PHP can resolve and use that dependency chain at runtime.
Important clarification:
I am not attempting to build a custom curl stack myself. I am using the curl/libcurl binaries already provided by the ApacheLounge distribution, which are confirmed working and include HTTP/3 support.
The full dependency chain is already staged and working at the CLI level.
The only missing piece is a php_curl.dll that will link against that external libcurl.dll instead of the bundled one.
Why this should be viable in my environment:
The PHP runtime is isolated and configured for deterministic DLL resolution:
* php-cgi.exe is launched from the PHP root
* NSSM Startup Directory is the PHP root
* NSSM PATH includes the PHP root
* NSSM PHPRC points to the PHP root
* extension_dir is explicitly set
* extension=curl loads normally
* curl.cainfo and openssl.cafile are explicitly configured
Additionally:
* The Apache → FastCGI handoff includes the required Windows transport shim ("//./") to ensure correct SCRIPT_FILENAME handling
* SCRIPT_FILENAME handling is explicitly controlled via ProxyFCGISetEnvIf, with separate handling for standard vhosts and alias-mounted applications
* This setup compensates for the "//./" transport shim and avoids common path misresolution issues on Apache VS18
* The Apache-provided curl (LibreSSL backend) is explicitly prioritised in PATH over the Windows System32 curl
This ensures that the HTTP/3-capable libcurl (with ngtcp2/nghttp3 and Brotli) is the active runtime dependency.
My CLI curl build:
| Code: |
curl 8.18.0 (Windows) libcurl/8.18.0 LibreSSL/4.2.1 zlib/1.3.1.zlib-ng
brotli/1.2.0 zstd/1.5.7 WinIDN libpsl/0.21.5 libssh2/1.11.1
nghttp2/1.68.0 ngtcp2/1.20.0 nghttp3/1.15.0 WinLDAP
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6
Kerberos Largefile libz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd
|
This is the libcurl build shipped with the ApacheLounge distribution, ensuring toolchain and ABI alignment with the Apache VS18 environment.
CLI verification of HTTP/3 (QUIC) functionality:
| Code: |
curl.exe -k -v --http3 https://www.google.com
* using HTTP/3
* [HTTP/3] [0] OPENED stream for https://www.google.com/
> GET / HTTP/3
> ...
> < HTTP/3 200
> |
This confirms that the libcurl build is successfully establishing HTTP/3 (QUIC) connections and completing full requests (HTTP/3 200 response).
PATH verification:
| Code: |
where curl.exe
F:\laragon\bin\apache\httpd-2.4.66-260223-Win64-VS18\bin\curl.exe
C:\Windows\System32\curl.exe
|
This confirms that the ApacheLounge curl (LibreSSL-based, HTTP/3-capable) is being resolved before the Windows System32 curl (Schannel backend).
Key point: HTTP/3 (QUIC), HTTP/2, and Brotli are fully functional in the ApacheLounge libcurl build — the remaining limitation is that PHP cannot currently utilize it due to how php_curl.dll is built.
Runtime context:
* OS: Windows 10 Pro 22H2 (build 19045.7058)
* Apache: Apache 2.4.66-260223 Win64 (VS18) (ApacheLounge)
* PHP: 8.5.4 NTS x64 VS17
* PHP source: Official php.net Windows build (php-8.5.4-nts-Win32-vs17-x64, VS17, NTS)
* SAPI: php-cgi.exe
* Integration: mod_proxy_fcgi
* Backend: fcgi://127.0.0.1:9000
* Process manager: NSSM
Note: I understand that HTTP/3 support depends on how libcurl is built and linked, and is not part of standard Windows PHP builds. My goal is specifically to enable PHP to use a QUIC-enabled libcurl build.
Questions:
1. Does anyone have, or would anyone be willing to build, a php_curl.dll that dynamically links to an external libcurl.dll?
2. If not, what are the required build flags / configuration changes to force dynamic linking when building ext/curl on Windows (VS17 toolchain)?
3. Is this feasible as an extension-only build, or would ABI/toolchain constraints require rebuilding a larger portion of PHP?
Thanks very much for any guidance. |
|
| Back to top |
|
|
|
|
|
|
