Trennen Sie libcurls Proxy-Header von den Website-Headern
Geben Sie libcurl getrennte Listen für Proxy- und Ziel-Header, und beachten Sie, dass die Weiterleitung im Klartext eine andere Sichtbarkeitsgrenze hat.
Trennen Sie bei einem vorhandenen libcurl-Handle die Listen der Ziel- und Proxy-Header ausdrücklich:
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);Halten Sie das konfigurierte Handle und die gültigen Listen für die Übertragung am Leben. CURLHEADER_SEPARATE unterscheidet Header, die bei CONNECT verwendet werden, von Headern, die für die Zielanfrage verwendet werden. Ältere Beispiele mit einheitlicher Richtlinie können die gewöhnliche Liste in beide Austausche legen.
| Anfragepfad | Bedeutung getrennter Listen |
|---|---|
| HTTPS in einem gewöhnlichen CONNECT-Tunnel | Der Proxy-Austausch kommt zuerst; danach folgen die HTTP-Ziel-Header innerhalb des Ziel-TLS. |
| Einfache HTTP-Weiterleitung | Der Proxy kann die Ziel-Header lesen, und libcurl kann beide zutreffenden Listen bei der einen weitergeleiteten Anfrage verwenden. |
Eine Routing-Markierung, die nur den Proxy betrifft, gehört zum Proxy-Austausch. Bei der Weiterleitung im Klartext kann ein beliebiges benutzerdefiniertes Feld den Ursprung erreichen, sofern die Weiterleitungsanordnung es nicht behandelt; der Name der Option ist keine Vertraulichkeitsgarantie.
Verwenden Sie unterstützte Anmeldedaten-Optionen zur Authentifizierung. Legen Sie bei operatordefinierten Metadaten fest, welcher Hop sie verbraucht und ob sie weitergeleitet werden dürfen, statt ein Passwort in ein generisches Feld zu setzen.
Wenn eine Markierung fehlt oder zu lecken scheint, identifizieren Sie die tatsächliche Anfrage, die sie enthält. Ein Header-Callback, der mehrere Austausche zeigt, kann korrekt getrennte Listen vermischt erscheinen lassen.