cURL-proxypoort versus bestemmingspoort
Houd de poort van een HTTPS-dienst in de bestemmings-URL en de poort van de tussenpartij in de proxy-URL, zonder ze via CURLOPT_PORT te overschrijven.
Een HTTPS-dienst op poort 8443 is bereikbaar via een HTTP-proxy op poort 8080. Die nummers beschrijven verschillende verbindingen:
$handle = curl_init('https://api.example:8443/status');
curl_setopt($handle, CURLOPT_PROXY, 'http://proxy.example:8080');
curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);De applicatie blijft verantwoordelijk voor de uitvoering, de foutafhandeling en de levensduur van de handle. Het fragment houdt de routing-invoer bij elkaar zonder de certificaatverificatie te wijzigen.
cURL maakt eerst verbinding met proxy.example:8080. Voor deze HTTPS-bestemming noemt het tunnelverzoek api.example:8443, en de TLS-identiteit blijft api.example.
CURLOPT_PORT is een overschrijving van de bestemmingspoort, niet van de poort van de proxy. Het op 443 zetten telkens wanneer een URL met https begint, kan een dienst overschrijven die bewust op 8443 draait. libcurl raadt aan de poort in de URL te kiezen in plaats van die optie te gebruiken.
Bij hergebruik van een handle moet je ook rekening houden met een eerdere expliciete poortoverschrijving. Een nieuwe URL maakt tegenstrijdige behouden opties niet makkelijker te interpreteren.
De tussenpartij moet CONNECT naar de gekozen bestemmingspoort toestaan. Een weigering voor 8443 is geen reden om de proxylistener te verplaatsen of TLS-validatie uit te schakelen.