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