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