Czy przepisywacz URL w Squidzie może modyfikować ciała odpowiedzi?
Przy rozszerzaniu proxy przekazującego oddziel wybór URL żądania od adaptacji odpowiedzi i odszyfrowywania TLS.
url_rewrite_program działa na decyzjach dotyczących URL żądania. Otrzymuje informacje o żądaniu i odpowiada przez protokół pomocniczy Squida; nie otrzymuje pobranego pliku, aby go edytować i odesłać.
| Pożądana operacja | Istotna granica |
|---|---|
| Przekierowanie przeglądarki lub wybór innego URL żądania | Rola pomocnika przepisującego URL na etapie żądania |
| Modyfikacja widocznego ciała odpowiedzi HTTP | Mechanizm adaptacji odpowiedzi, na przykład skonfigurowana modyfikacja odpowiedzi ICAP |
| Odczyt HTTP wewnątrz zwykłego CONNECT | Najpierw należy zakończyć TLS celu w odpowiednim układzie wdrożenia |
| Odszyfrowanie pliku zaszyfrowanego przez aplikację | Format, algorytm i klucz pliku, niezależnie od sposobu przesyłania |
Dwa ostatnie wiersze łatwo pomylić. Zwykły plik przesyłany przez HTTPS jest chroniony przez TLS. Plik zaszyfrowany przez aplikację może pozostać zaszyfrowany nawet po zakończeniu HTTPS. Wybór interfejsu adaptacji nie daje ani klucza aplikacji, ani jej algorytmu odszyfrowania.
Zwykły CONNECT przekazuje zaszyfrowane bajty tunelu. Pomocnik URL nie ujawnia wewnętrznej odpowiedzi; projekt wymagający inspekcji musi ustalić, czy ten ruch można i należy odszyfrować we wdrożeniu.
Tam, gdzie Squid może sprawdzić komunikat HTTP, usługa modyfikacji odpowiedzi nadal odpowiada za kodowania treści, zmienione długości i zachowanie przy błędzie. Wybierz interfejs po zdefiniowaniu transformacji, zamiast rozszerzać działający przykład przepisywania URL na etap przetwarzania, którego nigdy nie otrzymuje.