libcurl のプロキシヘッダーと Web サイトのヘッダーを分離する
libcurl にプロキシ用と宛先用のヘッダーリストを別々に渡し、平文転送では可視性の境界が異なることを認識します。
既存の libcurl ハンドルでは、宛先とプロキシのヘッダーリストを明示的に分離します:
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);転送中は、設定済みのハンドルと有効なリストを生かしておきます。CURLHEADER_SEPARATE は CONNECT で使われるヘッダーと、宛先リクエストに使われるヘッダーを区別します。古い統合ポリシーの例では、通常のリストを両方のやり取りに入れることがあります。
| リクエスト経路 | 別々のリストの意味 |
|---|---|
| 通常の CONNECT トンネル内の HTTPS | プロキシとのやり取りが先に行われ、その後、宛先 TLS 内で宛先の HTTP ヘッダーが続きます。 |
| 平文 HTTP 転送 | プロキシは宛先ヘッダーを読むことができ、libcurl は転送される 1 つのリクエストで該当する両方のリストを使えます。 |
プロキシ専用のルーティングマーカーはプロキシとのやり取りに属します。平文転送では、転送の仕組みが処理しない限り、任意のカスタムフィールドがオリジンに届く可能性があります。オプション名は機密性の保証ではありません。
認証にはサポートされている資格情報オプションを使用します。オペレーター定義のメタデータについては、どのホップが消費するのか、また一般的なフィールドにパスワードを置く代わりに転送してよいのかを確認します。
マーカーが見当たらない、または漏れているように見える場合は、それを含む実際のリクエストを特定します。複数のやり取りを示すヘッダーコールバックは、正しく分離されたリストを混在しているように見せることがあります。