Adskil libcurls proxy-headere fra webstedets headere
Giv libcurl separate lister med proxy- og destinationsheadere, og anerkend samtidig, at videresendelse i klartekst har en anden synlighedsgrænse.
For et eksisterende libcurl-handle skal du eksplicit adskille listerne med destinations- og proxy-headere:
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 konfigurerede handle og de gyldige lister i live under overførslen. CURLHEADER_SEPARATE skelner mellem headere, der bruges på CONNECT, og headere, der bruges til destinationsanmodningen. Ældre eksempler med samlet politik kan placere den almindelige liste i begge udvekslinger.
| Anmodningssti | Betydningen af separate lister |
|---|---|
| HTTPS i en almindelig CONNECT-tunnel | Proxy-udvekslingen kommer først; derefter følger destinations-HTTP-headere inde i destinationens TLS. |
| Almindelig HTTP-videresendelse | Proxien kan læse destinationsheaderne, og libcurl kan bruge begge relevante lister på den ene videresendte anmodning. |
En rutenmarkør, der kun gælder proxyen, hører til proxy-udvekslingen. Ved videresendelse i klartekst kan et vilkårligt brugerdefineret felt nå oprindelsen, medmindre videresendelsesordningen håndterer det; optionens navn er ingen garanti for fortrolighed.
Brug understøttede legitimationsindstillinger til godkendelse. For operatordefinerede metadata skal du fastslå, hvilket hop der forbruger dem, og om de må videresendes i stedet for at placere en adgangskode i et generisk felt.
Når en markør mangler eller ser ud til at lække, skal du identificere den faktiske anmodning, der indeholder den. Et header-callback, der viser flere udvekslinger, kan få korrekt adskilte lister til at se blandede ud.