Poate rescriitorul de URL al lui Squid să modifice corpurile răspunsurilor?
Păstrați selecția URL-ului cererii separată de adaptarea răspunsurilor și de decriptarea TLS atunci când extindeți un proxy de redirecționare.
url_rewrite_program lucrează asupra deciziilor privind URL-ul cererii. Primește informații despre cerere și răspunde prin protocolul auxiliar al lui Squid; nu primește un fișier descărcat pentru a-l edita și a-l returna.
| Operațiunea dorită | Limita relevantă |
|---|---|
| Redirecționarea browserului sau alegerea unui alt URL de cerere | Rolul auxiliarului de rescriere URL în etapa cererii |
| Modificarea unui corp de răspuns HTTP vizibil | Un mecanism de adaptare a răspunsurilor, cum ar fi modificarea răspunsului ICAP configurată |
| Citirea HTTP în interiorul unui CONNECT obișnuit | Mai întâi trebuie încheiat TLS-ul destinației într-o configurație de implementare adecvată |
| Decriptarea unui fișier criptat de o aplicație | Formatul, algoritmul și cheia fișierului, indiferent de transport |
Ultimele două rânduri se confundă ușor. Un fișier obișnuit transportat prin HTTPS este protejat de TLS. Un fișier criptat de o aplicație poate rămâne criptat chiar și după încheierea HTTPS. Alegerea unei interfețe de adaptare nu oferă nici cheia aplicației, nici algoritmul său de decriptare.
Un CONNECT obișnuit retransmite octeți de tunel criptați. Un auxiliar URL nu expune răspunsul interior; un proiect care necesită inspecție trebuie să stabilească dacă acel trafic poate și ar trebui să fie decriptat în implementare.
Acolo unde Squid poate inspecta mesajul HTTP, un serviciu de modificare a răspunsurilor rămâne responsabil pentru codificările conținutului, lungimile modificate și comportamentul la eșec. Alegeți interfața după ce definiți transformarea, în loc să extindeți un exemplu funcțional de rescriere URL la o etapă de procesare pe care nu o primește niciodată.