Squid の URL リライタはレスポンス本文を変更できますか？
フォワードプロキシを拡張するときは、リクエスト URL の選択をレスポンスの適応と TLS 復号から切り離してください。
url_rewrite_program はリクエスト URL の判断を担当します。リクエストの情報を受け取り、Squid のヘルパープロトコルで応答します。ダウンロード済みのファイルを受け取って編集し返すことはありません。
| 望む操作 | 関係する境界 |
|---|---|
| ブラウザをリダイレクトする、または別のリクエスト URL を選ぶ | リクエスト段階における URL リライタヘルパーの役割 |
| 可視の HTTP レスポンス本文を変更する | レスポンス適応の仕組み。たとえば 設定済みの ICAP レスポンス変更 |
| 通常の CONNECT の内側で HTTP を読む | まず宛先の TLS を適切な配備構成のもとで終端する必要がある |
| アプリケーションが暗号化したファイルを復号する | ファイルの形式・アルゴリズム・鍵であり、転送方法とは無関係 |
最後の二行は混同しやすいところです。HTTPS で運ばれる通常のファイルは TLS で保護されます。アプリケーションが暗号化したファイルは、HTTPS を終端した後でも暗号化されたまま残りえます。適応インターフェースを選んでも、アプリケーションの鍵も復号アルゴリズムも得られません。
通常の CONNECT は暗号化されたトンネルのバイトを中継します。URL ヘルパーは内側のレスポンスを公開しません。検査を必要とする設計は、その通信を配備内で復号できるか、また復号すべきかを明確にしなければなりません。
Squid が HTTP メッセージを検査できる場合でも、レスポンス変更サービスは内容の符号化、変更された長さ、失敗時の振る舞いを引き続き担います。変換を定義したうえでインターフェースを選び、動作する URL リライトの例を、決して受け取らない処理段階へ拡張しないでください。