Hello, I'm not sure I get what the issue is here.

"Host": "3.211.1.78"

Where is this line coming from?

Note that HTTP/1.1 section 5.3.2 tells that the full uri must be used when going through a proxy:
https://tools.ietf.org/html/rfc7230#section-5.3.2

So this can break many things.

can you give more hints about this? could your proxy be non-compliant? How does it behave when using CurlHttpClient?

Where is this line coming from?

I'm not sure what changed theHost header for now.

could your proxy be non-compliant?

I'm testing it withprivoxy, I don't know which proxy is compliant if it isn't.
CurlHttpClient works just fine, same result as settingrequest_fulluri to false.

Tested on Symfony 5.1.6, Debian 10, PHP (deb.sury.org) 7.4.10, curl 7.72.0 (from unstable repo to enable the debug log)
Privoxy working on 127.0.0.1:7777 version 3.0.28, default config, without sending/redirecting the traffic to another proxy (e.g. SOCKS)

<?phpdeclare(strict_types=1);useSymfony\Component\HttpClient\CurlHttpClient;useSymfony\Component\HttpClient\NativeHttpClient;useSymfony\Component\HttpClient\HttpClient;require__DIR__ .'/vendor/autoload.php';$client =newNativeHttpClient();$resp =$client->request('GET','https://httpbin.org/get');echo$resp->getContent();echo$resp->getInfo('debug');

Withoutrequest_fulluri

{  "args": {},  "headers": {    "Accept": "*/*",    "Accept-Encoding": "gzip",    "Host": "httpbin.org",    "User-Agent": "Symfony HttpClient/Native",    "X-Amzn-Trace-Id": "Root=1-5f75cd34-5daa0a902c40e8df6a4cdd5b"  },  "origin": "xxx.xxx.xxx.xxx",  "url": "https://httpbin.org/get"}* Hostname was NOT found in DNS cache* Added httpbin.org:0:34.194.129.11 to DNS cache* Establish HTTP proxy tunnel to tcp://127.0.0.1:7777> GET https://34.194.129.11/get HTTP/1.1Accept: */*Accept-Encoding: gzipHost: httpbin.orgUser-Agent: Symfony HttpClient/Native< HTTP/1.1 200 OK< Date: Thu, 01 Oct 2020 12:36:04 GMT< Content-Type: application/json< Content-Length: 300< Connection: close< Server: gunicorn/19.9.0< Access-Control-Allow-Origin: *< Access-Control-Allow-Credentials: true<

CurlHttpClient

{  "args": {},  "headers": {    "Accept": "*/*",    "Accept-Encoding": "gzip",    "Host": "httpbin.org",    "User-Agent": "Symfony HttpClient/Curl",    "X-Amzn-Trace-Id": "Root=1-5f75cbd9-51a4f7a44f1eaa3326be6796"  },  "origin": "xxx.xxx.xxx.xxx",  "url": "https://httpbin.org/get"}* Uses proxy env variable https_proxy == 'http://127.0.0.1:7777'*   Trying 127.0.0.1:7777...* Connected to 127.0.0.1 (127.0.0.1) port 7777 (#0)* allocate connect buffer!* Establish HTTP proxy tunnel to httpbin.org:443> CONNECT httpbin.org:443 HTTP/1.1Host: httpbin.org:443Proxy-Connection: Keep-Alive< HTTP/1.1 200 Connection established<* Proxy replied 200 to CONNECT request* CONNECT phase completed!* ALPN, offering h2* ALPN, offering http/1.1* successfully set certificate verify locations:*   CAfile: /etc/ssl/certs/ca-certificates.crt  CApath: /etc/ssl/certs* CONNECT phase completed!* CONNECT phase completed!* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256* ALPN, server accepted to use h2* Server certificate:*  subject: CN=httpbin.org*  start date: Jan 18 00:00:00 2020 GMT*  expire date: Feb 18 12:00:00 2021 GMT*  subjectAltName: host "httpbin.org" matched cert's "httpbin.org"*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon*  SSL certificate verify ok.* Using HTTP2, server supports multi-use* Connection state changed (HTTP/2 confirmed)* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0* Using Stream ID: 1 (easy handle 0x556304296990)> GET /get HTTP/2Host: httpbin.orgaccept: */*user-agent: Symfony HttpClient/Curlaccept-encoding: gzip* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!< HTTP/2 200< date: Thu, 01 Oct 2020 12:30:17 GMT< content-type: application/json< content-length: 298< server: gunicorn/19.9.0< access-control-allow-origin: *< access-control-allow-credentials: true<* Connection #0 to host 127.0.0.1 left intact

can you give more hints about this?

So for example httpbin can be accessed likecurl -k https://3.211.1.78/get, but many others don't.
TheHost information is lost, a web server uses theHost to find out which website is being accessed.

According tohttps://www.php.net/manual/fr/context.http.php#context.http.request-fulluri, therequest_fulluri context param is precisely creating non-standard requests, so that they work with non-standard proxies.

Thanks for the insights. Looking at the details, this means that the fulluri should be used only when https isnot in use.

The patch should bestream_context_set_option($context, 'http', 'request_fulluri', !$isSsl);

$isSsl being a new argument on the method, whose value is'https:' === $url['scheme']

Thanks for the insights. Looking at the details, this means that the fulluri should be used only when https isnot in use.

why would it depend on https ?

• When doing https, the CONNECT method is used and the remaining of the stream is encrypted: the remote server must see only the path
• When doing http, GET is used: the proxy sees the headers and routes accordingly. It does so according to section 5.3.2 above, using the full URI.

Patch applied. Worked with privoxy.
But my"non-standard-compliant" HTTP proxy (v2ray written in Go)
seems needrequest_fulluri to be false to work...
Could we make it configurable?

Thank you@bohanyang.

But my "non-standard-compliant" HTTP proxy (v2ray written in Go) seems need request_fulluri to be false to work...

Can you open an issue on the v2ray repo to tell them about this? It should be fixed on their side IMHO.

@nicolas-grekas my understanding of the HTTP/1.1 spec is that the request to the proxy should beGET https://httpbin.org/get, notGET https://3.211.1.78/get as the HTTP/1.1 proxy would replace theHOST header. So the PHP behavior forrequest_fulluri does not seem to be the HTTP/1.1 behavior.

the request to the proxy should be GEThttps://httpbin.org/get, not GEThttps://3.211.1.78/get

It should, but here this conflicts with the local DNS resolver/cache. But does it matter?

the HTTP/1.1 proxy would replace the HOST header

Why would it?

Why would it?

because ofhttps://tools.ietf.org/html/rfc7230#section-5.4:

When a proxy receives a request with an absolute-form of
request-target, the proxy MUST ignore the received Host header field
(if any) and instead replace it with the host information of the
request-target. A proxy that forwards such a request MUST generate a
new Host field-value based on the received request-target rather than
forward the received Host field-value.

@stof I missed that part, grrr. This means we have a conflict between the local DNS resolver/cache and proxies when using NativeHttpClient. I'm going to submit a PR to account for this.

@bohanyang maybe this will fix your issue withv2ray, I'll ping you so that you could give it a try if you don't mind.

@bohanyang can you please test with#38375?