Il riscrittore di URL di Squid può modificare i corpi delle risposte?
Tieni la selezione dell’URL della richiesta separata dall’adattamento delle risposte e dalla decifratura TLS quando estendi un proxy di inoltro.
url_rewrite_program opera sulle decisioni relative all’URL della richiesta. Riceve informazioni sulla richiesta e risponde tramite il protocollo ausiliario di Squid; non riceve un file scaricato da modificare e restituire.
| Operazione desiderata | Confine pertinente |
|---|---|
| Reindirizzare il browser o scegliere un altro URL di richiesta | Il ruolo dell’ausiliario di riscrittura URL nella fase di richiesta |
| Modificare un corpo di risposta HTTP visibile | Un meccanismo di adattamento delle risposte, come la modifica della risposta ICAP configurata |
| Leggere HTTP all’interno di un CONNECT ordinario | Il TLS di destinazione deve prima essere terminato in un’adeguata configurazione di distribuzione |
| Decifrare un file cifrato da un’applicazione | Il formato, l’algoritmo e la chiave del file, indipendentemente dal trasporto |
Le ultime due righe si confondono facilmente. Un file ordinario trasportato su HTTPS è protetto da TLS. Un file cifrato da un’applicazione può restare cifrato anche dopo la fine di HTTPS. Scegliere un’interfaccia di adattamento non fornisce né la chiave dell’applicazione né il suo algoritmo di decifratura.
Un CONNECT ordinario inoltra byte di tunnel cifrati. Un ausiliario URL non espone la risposta interna; un progetto che richiede ispezione deve stabilire se quel traffico possa e debba essere decifrato nella distribuzione.
Dove Squid può ispezionare il messaggio HTTP, un servizio di modifica delle risposte resta responsabile delle codifiche del contenuto, delle lunghezze modificate e del comportamento in caso di errore. Scegli l’interfaccia dopo aver definito la trasformazione, invece di estendere un esempio funzionante di riscrittura URL a una fase di elaborazione che non riceve mai.