Může přepisovač URL v Squidu upravovat těla odpovědí?
Při rozšiřování dopředného proxy udržujte volbu URL požadavku oddělenou od adaptace odpovědí a od šifrování TLS.
url_rewrite_program pracuje s rozhodnutími o URL požadavku. Přijímá informace o požadavku a odpovídá pomocí pomocného protokolu Squidu; nedostává stažený soubor, který by upravil a vrátil.
| Požadovaná operace | Příslušná hranice |
|---|---|
| Přesměrovat prohlížeč nebo zvolit jinou URL požadavku | Role pomocníka pro přepis URL ve fázi požadavku |
| Upravit viditelné tělo odpovědi HTTP | Prostředek pro adaptaci odpovědí, například nakonfigurovaná úprava odpovědi ICAP |
| Číst HTTP uvnitř běžného CONNECT | TLS cíle musí být nejprve ukončeno v rámci vhodného uspořádání nasazení |
| Dešifrovat soubor zašifrovaný aplikací | Formát souboru, algoritmus a klíč, bez ohledu na jeho přenos |
Poslední dva řádky se snadno zaměňují. Běžný soubor přenášený přes HTTPS chrání TLS. Soubor zašifrovaný aplikací může zůstat zašifrovaný i poté, co bylo HTTPS ukončeno. Volba rozhraní pro adaptaci neposkytuje ani klíč aplikace, ani její dešifrovací algoritmus.
Běžný CONNECT přenáší zašifrované bajty tunelu. Pomocník URL nevystavuje vnitřní odpověď; návrh vyžadující inspekci musí určit, zda je tento provoz v nasazení možné a žádoucí dešifrovat.
Tam, kde Squid může zkontrolovat zprávu HTTP, služba pro úpravu odpovědí stále odpovídá za kódování obsahu, změněné délky a chování při selhání. Rozhraní vyberte až po definování transformace, místo abyste funkční příklad přepisu URL rozšířili do fáze zpracování, kterou nikdy nedostává.