¿Puede el reescritor de URL de Squid modificar los cuerpos de las respuestas?
Mantén la selección de la URL de la petición separada de la adaptación de respuestas y del descifrado TLS al ampliar un proxy de reenvío.
url_rewrite_program trabaja sobre decisiones de URL de petición. Recibe información de la petición y responde mediante el protocolo auxiliar de Squid; no recibe un archivo descargado para editarlo y devolverlo.
| Operación deseada | Frontera pertinente |
|---|---|
| Redirigir el navegador o elegir otra URL de petición | El papel del auxiliar de reescritura de URL en la etapa de petición |
| Modificar un cuerpo de respuesta HTTP visible | Un mecanismo de adaptación de respuestas, como la modificación de respuestas por ICAP configurada |
| Leer HTTP dentro de un CONNECT ordinario | Primero debe terminarse el TLS de destino bajo un despliegue adecuado |
| Descifrar un archivo cifrado por una aplicación | El formato, el algoritmo y la clave del archivo, con independencia de su transporte |
Las dos últimas filas se confunden con facilidad. Un archivo normal transportado por HTTPS está protegido por TLS. Un archivo cifrado por una aplicación puede seguir cifrado incluso después de haber terminado HTTPS. Elegir una interfaz de adaptación no aporta ni la clave de la aplicación ni su algoritmo de descifrado.
Un CONNECT ordinario retransmite bytes de túnel cifrados. Un auxiliar de URL no expone la respuesta interna; un diseño que exija inspección debe determinar si ese tráfico puede y debe descifrarse en el despliegue.
Donde Squid puede inspeccionar el mensaje HTTP, un servicio de modificación de respuestas sigue siendo responsable de las codificaciones de contenido, las longitudes modificadas y el comportamiento ante fallos. Elige la interfaz después de definir la transformación, en lugar de extender un ejemplo funcional de reescritura de URL a una etapa de procesamiento que nunca recibe.