A mundet rishkruesi i URL-ve të Squid të modifikojë trupat e përgjigjeve?
Mbajini zgjedhjen e URL-së së kërkesës të ndarë nga përshtatja e përgjigjeve dhe dekriptimi TLS kur zgjeroni një proxy përpara.
url_rewrite_program punon mbi vendimet për URL-në e kërkesës. Merr informacion rreth kërkesës dhe përgjigjet përmes protokollit ndihmës të Squid; nuk merr një skedar të shkarkuar për ta redaktuar dhe kthyer.
| Operacioni i dëshiruar | Kufiri përkatës |
|---|---|
| Të ridrejtohet shfletuesi ose të zgjidhet një URL tjetër kërkese | Roli i ndihmësit të rishkrimit të URL-së në fazën e kërkesës |
| Të modifikohet një trup përgjigjeje HTTP i dukshëm | Një mekanizëm përshtatjeje përgjigjesh, si modifikimi i konfiguruar i përgjigjes ICAP |
| Të lexohet HTTP brenda një CONNECT të zakonshëm | Së pari duhet të përfundojë TLS-i i destinacionit në një skemë të përshtatshme vendosjeje |
| Të dekriptohet një skedar i kriptuar nga një aplikacion | Formati, algoritmi dhe çelësi i skedarit, pavarësisht nga transporti |
Dy rreshtat e fundit ngatërrohen lehtë. Një skedar i zakonshëm i transportuar përmes HTTPS mbrohet nga TLS. Një skedar i kriptuar nga një aplikacion mund të mbetet i kriptuar edhe pasi HTTPS të ketë përfunduar. Zgjedhja e një ndërfaqeje përshtatjeje nuk jep as çelësin e aplikacionit as algoritmin e tij të dekriptimit.
Një CONNECT i zakonshëm përcjell bajt të kriptuar të tunelit. Një ndihmës URL nuk e zbulon përgjigjen e brendshme; një projekt që kërkon inspektim duhet të përcaktojë nëse ai trafik mund dhe duhet të dekriptohet në vendosje.
Aty ku Squid mund të inspektojë mesazhin HTTP, një shërbim modifikimi përgjigjesh vazhdon të jetë përgjegjës për kodimet e përmbajtjes, gjatësitë e ndryshuara dhe sjelljen në dështim. Zgjidhni ndërfaqen pasi të keni përcaktuar transformimin, në vend që të zgjeroni një shembull funksional të rishkrimit të URL-së në një fazë përpunimi që nuk e merr kurrë.