Может ли переписыватель URL в Squid изменять тела ответов?
Держите выбор URL запроса отдельно от адаптации ответов и расшифровки TLS, когда расширяете форвардный прокси.
url_rewrite_program работает с решениями об URL запроса. Он получает сведения о запросе и отвечает через вспомогательный протокол Squid; он не получает загруженный файл, чтобы отредактировать и вернуть его.
| Желаемая операция | Соответствующая граница |
|---|---|
| Перенаправить браузер или выбрать другой URL запроса | Роль помощника переписывания URL на этапе запроса |
| Изменить видимое тело HTTP-ответа | Средство адаптации ответов, например настроенное изменение ответа через ICAP |
| Читать HTTP внутри обычного CONNECT | Сначала нужно завершить TLS назначения в подходящей схеме развёртывания |
| Расшифровать файл, зашифрованный приложением | Формат, алгоритм и ключ файла, независимо от способа передачи |
Последние две строки легко перепутать. Обычный файл, передаваемый по HTTPS, защищён TLS. Файл, зашифрованный приложением, может оставаться зашифрованным даже после завершения HTTPS. Выбор интерфейса адаптации не даёт ни ключа приложения, ни его алгоритма расшифровки.
Обычный CONNECT передаёт зашифрованные байты туннеля. Помощник URL не раскрывает внутренний ответ; проект, требующий проверки, должен определить, можно ли и нужно ли расшифровывать этот трафик в развёртывании.
Там, где Squid может проверить HTTP-сообщение, служба изменения ответов по-прежнему отвечает за кодировки содержимого, изменённые длины и поведение при сбое. Выбирайте интерфейс после того, как определена трансформация, вместо того чтобы расширять рабочий пример переписывания URL на этап обработки, который он никогда не получает.