Pode o reescritor de URL de Squid modificar os corpos das respostas?
Manteña a selección da URL da petición separada da adaptación de respostas e do descifrado TLS cando amplía un proxy de reenvío.
url_rewrite_program traballa sobre decisións de URL de petición. Recibe información da petición e responde mediante o protocolo auxiliar de Squid; non recibe un ficheiro descargado para editalo e devolvelo.
| Operación desexada | Fronteira relevante |
|---|---|
| Redirixir o navegador ou escoller outra URL de petición | O papel do auxiliar de reescritura de URL na etapa de petición |
| Modificar un corpo de resposta HTTP visible | Un mecanismo de adaptación de respostas, como a modificación de respostas ICAP configurada |
| Ler HTTP dentro dun CONNECT común | Primeiro débese rematar o TLS de destino nun despregamento axeitado |
| Descifrar un ficheiro cifrado por unha aplicación | O formato, o algoritmo e a chave do ficheiro, independentemente do seu transporte |
As dúas últimas filas confúndense facilmente. Un ficheiro común transportado por HTTPS está protexido por TLS. Un ficheiro cifrado por unha aplicación pode seguir cifrado mesmo despois de rematar HTTPS. Escoller unha interface de adaptación non fornece nin a chave da aplicación nin o seu algoritmo de descifrado.
Un CONNECT común retransmite bytes de túnel cifrados. Un auxiliar de URL non expón a resposta interior; un deseño que requira inspección debe determinar se ese tráfico pode e debe descifrarse no despregamento.
Onde Squid pode inspeccionar a mensaxe HTTP, un servizo de modificación de respostas segue a ser responsable das codificacións de contido, das lonxitudes modificadas e do comportamento ante fallos. Escolla a interface despois de definir a transformación, en lugar de estender un exemplo funcional de reescritura de URL a unha etapa de procesamento que nunca recibe.