cURL-proksiepoort teenoor bestemmingspoort
Hou die poort van 'n HTTPS-diens in sy bestemmings-URL en die tussenparty se poort in die proksie-URL, sonder om dit deur CURLOPT_PORT te oorskryf.
'n HTTPS-diens op poort 8443 is bereikbaar deur 'n HTTP-proksie op poort 8080. Daardie nommers beskryf verskillende verbindings:
$handle = curl_init('https://api.example:8443/status');
curl_setopt($handle, CURLOPT_PROXY, 'http://proxy.example:8080');
curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);Die toepassing besit steeds die uitvoering, foutafhandeling en die lewensduur van die handvatsel. Die kodesnip hou die roeteringsinvoer bymekaar sonder om sertifikaatverifikasie te verander.
cURL maak eers aan proxy.example:8080 verbinding. Vir hierdie HTTPS-bestemming noem die tonnelversoek api.example:8443, en die TLS-identiteit bly api.example.
CURLOPT_PORT is 'n bestemmingspoort-oorskrywing, nie die proksie se poort nie. Om dit op 443 te stel wanneer 'n URL met https begin, kan 'n diens oorskryf wat doelbewus op 8443 gehuisves word. libcurl beveel aan om die poort in die URL te kies eerder as om daardie opsie te gebruik.
Wanneer 'n handvatsel hergebruik word, moet jy ook enige vroeëre eksplisiete poort-oorskrywing in ag neem. 'n Nuwe URL maak nie teensprekende behoue opsies makliker om te interpreteer nie.
Die tussenparty moet CONNECT na die gekose bestemmingspoort toelaat. 'n Weiering vir 8443 is nie 'n rede om die proksie-listener te skuif of TLS-validering af te skakel nie.