Може ли Squid-овиот препишувач на URL да менува тела на одговори?
Одделете го изборот на URL на барањето од прилагодувањето на одговори и TLS-дешифрирањето кога го проширувате напредниот прокси.
url_rewrite_program работи на одлуки за URL на барањето. Прима информации за барањето и одговара преку помошниот протокол на Squid; не прима преземена датотека за да ја уреди и врати.
| Посакувана операција | Релевантна граница |
|---|---|
| Пренасочување на прелистувачот или избор на друг URL на барање | Улогата на помошникот за препишување URL во фазата на барање |
| Менување на видливо тело на HTTP одговор | Средство за прилагодување одговори, како конфигурирана промена на одговор преку ICAP |
| Читање HTTP во обичен CONNECT | Најпрво треба да се заврши TLS-от на одредиштето во соодветен распоред на распоредување |
| Дешифрирање на датотека шифрирана од апликација | Форматот, алгоритмот и клучот на датотеката, независно од преносот |
Последните два реда лесно се мешаат. Обична датотека пренесена преку HTTPS е заштитена со TLS. Датотека шифрирана од апликација може да остане шифрирана и по завршувањето на HTTPS. Изборот на интерфејс за прилагодување не го дава ниту клучот на апликацијата ниту нејзиниот алгоритам за дешифрирање.
Обичниот CONNECT пренесува шифрирани бајти на тунелот. Помошникот за URL не го открива внатрешниот одговор; проект што бара проверка мора да утврди дали тој сообраќај може и треба да се дешифрира во распоредувањето.
Каде Squid може да ја провери HTTP пораката, услугата за промена на одговори сè уште одговара за кодирањата на содржината, променетите должини и однесувањето при грешка. Изберете го интерфејсот откако ќе ја дефинирате трансформацијата, наместо да го проширите работниот пример за препишување URL во фаза на обработка што таа никогаш не ја прима.