Skill libcurls proxy-hoder fra nettstedets hoder
Gi libcurl separate lister med proxy- og destinasjonshoder, og erkjenne at videresending i klartekst har en annen synlighetsgrense.
For et eksisterende libcurl-håndtak, skill listene med destinasjons- og proxy-hoder eksplisitt:
curl_easy_setopt(handle, CURLOPT_HEADEROPT, (long)CURLHEADER_SEPARATE);
curl_easy_setopt(handle, CURLOPT_PROXYHEADER, proxy_headers);
curl_easy_setopt(handle, CURLOPT_HTTPHEADER, origin_headers);Hold det konfigurerte håndtaket og de gyldige listene i live under overføringen. CURLHEADER_SEPARATE skiller hoder som brukes på CONNECT, fra hoder som brukes for destinasjonsforespørselen. Eldre eksempler med enhetlig policy kan legge den vanlige listen i begge utvekslingene.
| Forespørselssti | Betydningen av separate lister |
|---|---|
| HTTPS i en vanlig CONNECT-tunnel | Proxy-utvekslingen kommer først; deretter følger destinasjonens HTTP-hoder inne i destinasjonens TLS. |
| Vanlig HTTP-videresending | Proxyen kan lese destinasjonshodene, og libcurl kan bruke begge de aktuelle listene på den ene videresendte forespørselen. |
En rutenmarkør som bare gjelder proxyen, hører til proxy-utvekslingen. Ved videresending i klartekst kan et vilkårlig egendefinert felt nå opphavet med mindre videresendingsordningen håndterer det; navnet på alternativet er ingen garanti for konfidensialitet.
Bruk støttede legitimasjonsalternativer for autentisering. For operatørdefinerte metadata, fastslå hvilket hopp som bruker dem, og om de kan videresendes i stedet for å legge et passord i et generisk felt.
Når en markør mangler eller ser ut til å lekke, identifiser den faktiske forespørselen som inneholder den. En header-callback som viser flere utvekslinger, kan få korrekt adskilte lister til å se blandet ut.