Kann der URL-Rewriter von Squid Antwortkörper verändern?
Halten Sie die Auswahl der Anforderungs-URL getrennt von der Antwortanpassung und der TLS-Entschlüsselung, wenn Sie einen Forward-Proxy erweitern.
url_rewrite_program arbeitet an Entscheidungen zur Anforderungs-URL. Er erhält Informationen zur Anforderung und antwortet über das Helferprotokoll von Squid; er erhält keine heruntergeladene Datei, die er bearbeiten und zurückgeben könnte.
| Gewünschte Operation | Relevante Grenze |
|---|---|
| Den Browser umleiten oder eine andere Anforderungs-URL wählen | Die Rolle des URL-Rewriting-Helfers in der Anforderungsphase |
| Einen sichtbaren HTTP-Antwortkörper verändern | Eine Einrichtung zur Antwortanpassung, etwa konfigurierte ICAP-Antwortänderung |
| HTTP innerhalb eines gewöhnlichen CONNECT lesen | Das TLS des Ziels muss zuerst in einer geeigneten Bereitstellungsregelung beendet werden |
| Eine anwendungsverschlüsselte Datei entschlüsseln | Format, Algorithmus und Schlüssel der Datei, unabhängig von ihrem Transport |
Die letzten beiden Zeilen werden leicht verwechselt. Eine gewöhnliche Datei, die über HTTPS übertragen wird, ist durch TLS geschützt. Eine anwendungsverschlüsselte Datei kann auch nach dem Beenden von HTTPS verschlüsselt bleiben. Die Wahl einer Anpassungsschnittstelle liefert weder den Schlüssel der Anwendung noch deren Entschlüsselungsalgorithmus.
Ein gewöhnliches CONNECT leitet verschlüsselte Tunnelbytes weiter. Ein URL-Helfer legt die innere Antwort nicht offen; ein Entwurf, der Prüfung verlangt, muss klären, ob dieser Datenverkehr in der Bereitstellung entschlüsselt werden kann und sollte.
Wo Squid die HTTP-Nachricht prüfen kann, verantwortet ein Dienst zur Antwortänderung weiterhin Inhaltkodierungen, geänderte Längen und das Verhalten bei Fehlern. Wählen Sie die Schnittstelle, nachdem Sie die Transformation definiert haben, statt ein funktionierendes Beispiel zum URL-Rewriting auf eine Verarbeitungsstufe auszudehnen, die es nie erhält.