Composer Proxy Settings: Retire the REQUEST_FULLURI Flags

Composer's old HTTP_PROXY_REQUEST_FULLURI and related FULLURI workarounds are no longer required or used in the documented implementation. An ignored flag cannot repair the running client's route.

For command-line Composer in a POSIX shell, export the supported proxy variables before invoking Composer from that shell:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080

Lowercase names are preferred. Both values can begin with http:// when the proxy itself uses ordinary HTTP; an HTTPS destination does not require an HTTPS connection to the proxy. Replace the example endpoint with the approved service. For public package downloads where a public intermediary is allowed, choose an HTTP candidate from the HTTP proxy list.

An IDE or build agent needs the values in its own process environment. Changing a persistent setting afterward does not update an already running process.

When Composer runs outside the CLI

For HTTP requests in a non-CLI context, Composer does not use http_proxy or HTTP_PROXY. It documents CGI_HTTP_PROXY instead, protecting against request headers being mistaken for trusted proxy configuration. Do not copy the shell solution into a web application or take proxy settings from an untrusted request.

Read the failed operation

An unresolved proxy name, refused connection, 407 challenge and certificate failure point to different stages. Use the first meaningful error rather than apply old IPv6 or certificate-verification workarounds.

If Composer's HTTP download works but a Git-backed dependency fails, inspect the separate Git process, its route and its account. That is a different consumer from the successful Composer download.