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