Kan Squids URL-omskriver ændre svarbodyer?
Hold valget af anmodnings-URL adskilt fra tilpasning af svar og TLS-dekryptering, når du udvider en videresendende proxy.
url_rewrite_program arbejder på beslutninger om anmodnings-URL'er. Det modtager oplysninger om anmodningen og svarer via Squids hjælperprotokol; det modtager ikke en downloadet fil, som det kan redigere og returnere.
| Ønsket handling | Relevant grænse |
|---|---|
| Omdiriger browseren, eller vælg en anden anmodnings-URL | URL-omskrivningshjælperens rolle i anmodningsfasen |
| Ændr en synlig HTTP-svarbody | En facilitet til svartilpasning, f.eks. konfigureret ICAP-svarændring |
| Læs HTTP inde i en almindelig CONNECT | Destinationens TLS skal først afsluttes under en passende udrulningsordning |
| Dekryptér en fil, der er krypteret af en applikation | Filens format, algoritme og nøgle, uanset hvordan den transporteres |
De sidste to rækker er lette at forveksle. En almindelig fil, der overføres via HTTPS, beskyttes af TLS. En fil, der er krypteret af en applikation, kan forblive krypteret, selv efter at HTTPS er afsluttet. Valg af en tilpasningsgrænseflade giver hverken applikationens nøgle eller dens dekrypteringsalgoritme.
Almindelig CONNECT videresender krypterede tunnelbytes. En URL-hjælper eksponerer ikke det indre svar; et design, der kræver inspektion, må afgøre, om den trafik kan og bør dekrypteres i udrulningen.
Hvor Squid kan inspicere HTTP-meddelelsen, ejer en tjeneste til svarændring stadig indholdskodninger, ændrede længder og fejlhåndtering. Vælg grænsefladen, efter at transformationen er defineret, i stedet for at udvide et fungerende eksempel på URL-omskrivning til en behandlingsfase, det aldrig modtager.