Squid から選択した HTTP リクエストを HTTPS へリダイレクトする

Squid はブラウザに対し、選択した HTTP URL を HTTPS で再試行するよう要求できます。宛先はすでに対応するリソースを HTTPS で提供している必要があります。Raspberry Pi 上で Squid を動かしても、その能力がウェブサイト側に生まれるわけではありません。

Squid 7 の url_rewrite_program インターフェースでは、helper は次のようなクライアントリダイレクトを返せます:

OK status=307 url="https://www.example.com/help"

これは一致するリクエストに対する 1 つの例示的な helper 応答であり、完全な helper プログラムではありません。ブラウザはリダイレクトを受け取り、HTTPS URL へ新しいリクエストを行います。アップグレード方針の外にある URL は OK を受け取り、変更されないままにできます。

HTTPS 対応先の既知のリストを使い、受信 URL を解析してください。意図したパスと query を保ち、明示的なポートを考慮し、リクエストメソッドを意識して扱います。すべての http プレフィックスを盲目的に置き換えると、各オリジンに同等の HTTPS サービスがあると仮定したことになります。

helper はインストールされた Squid のバージョンのプロトコルに従って、入力行ごとに応答しなければなりません。並行 helper チャネルが有効な場合は、応答内のチャネル識別子を保ってください。古い裸の 301:URL の例は、現在の result-and-key/value 形式と交換可能ではありません。

ブラウザが新しい URL を知る必要がある場合はクライアントリダイレクトを選びます。rewrite-url 応答は代わりに、クライアントの元のリクエストの背後で別の URL を取得するよう Squid に求め、アプリケーションの URL と状態を不整合にし得ます。

最初の HTTP リクエストは、helper がリダイレクトできるより前にすでに Squid へ届いています。この方針はそのリクエストを遡って保護できません。TLS は後続の HTTPS 接続で始まります。CONNECT トンネルだけでは暗号化は提供されません。