Le réécrivain d’URL de Squid peut-il modifier les corps de réponse ?
Gardez la sélection de l’URL de requête distincte de l’adaptation des réponses et du déchiffrement TLS lorsque vous étendez un proxy de transfert.
url_rewrite_program intervient sur les décisions d’URL de requête. Il reçoit des informations sur la requête et répond via le protocole d’assistance de Squid ; il ne reçoit pas un fichier téléchargé pour le modifier et le renvoyer.
| Opération souhaitée | Frontière concernée |
|---|---|
| Rediriger le navigateur ou choisir une autre URL de requête | Le rôle de l’assistant de réécriture d’URL à l’étape de la requête |
| Modifier un corps de réponse HTTP visible | Un dispositif d’adaptation des réponses, comme la modification de réponse ICAP configurée |
| Lire le HTTP à l’intérieur d’un CONNECT ordinaire | Le TLS de destination doit d’abord être terminé dans un déploiement approprié |
| Déchiffrer un fichier chiffré par une application | Le format, l’algorithme et la clé du fichier, quel que soit son transport |
Les deux dernières lignes sont faciles à confondre. Un fichier ordinaire transporté par HTTPS est protégé par TLS. Un fichier chiffré par une application peut rester chiffré même après la fin de HTTPS. Choisir une interface d’adaptation ne fournit ni la clé de l’application ni son algorithme de déchiffrement.
Un CONNECT ordinaire relaie des octets de tunnel chiffrés. Un assistant d’URL n’expose pas la réponse interne ; une conception exigeant une inspection doit déterminer si ce trafic peut et doit être déchiffré dans le déploiement.
Là où Squid peut inspecter le message HTTP, un service de modification de réponse reste responsable des encodages de contenu, des longueurs modifiées et du comportement en cas d’échec. Choisissez l’interface après avoir défini la transformation, plutôt que d’étendre un exemple fonctionnel de réécriture d’URL à une étape de traitement qu’il ne reçoit jamais.