O reescritor de URL do Squid pode modificar corpos de resposta?
Mantenha a seleção do URL do pedido separada da adaptação de respostas e da desencriptação TLS ao ampliar um proxy de encaminhamento.
url_rewrite_program atua sobre decisões de URL do pedido. Recebe informações sobre o pedido e responde através do protocolo auxiliar do Squid; não recebe um ficheiro descarregado para o editar e devolver.
| Operação pretendida | Fronteira relevante |
|---|---|
| Redirecionar o navegador ou escolher outro URL de pedido | O papel do auxiliar de reescrita de URL na fase do pedido |
| Modificar um corpo de resposta HTTP visível | Um mecanismo de adaptação de respostas, como a modificação de resposta ICAP configurada |
| Ler HTTP dentro de um CONNECT comum | O TLS de destino tem de ser primeiro terminado numa disposição de implementação adequada |
| Desencriptar um ficheiro cifrado por uma aplicação | O formato, o algoritmo e a chave do ficheiro, independentemente do transporte |
As duas últimas linhas confundem-se facilmente. Um ficheiro comum transportado por HTTPS é protegido por TLS. Um ficheiro cifrado por uma aplicação pode permanecer cifrado mesmo depois de o HTTPS terminar. Escolher uma interface de adaptação não fornece nem a chave da aplicação nem o seu algoritmo de desencriptação.
Um CONNECT comum retransmite bytes de túnel cifrados. Um auxiliar de URL não expõe a resposta interna; um projeto que exija inspeção tem de determinar se esse tráfego pode e deve ser desencriptado na implementação.
Onde o Squid consegue inspecionar a mensagem HTTP, um serviço de modificação de respostas continua a ser responsável pelas codificações de conteúdo, pelos comprimentos alterados e pelo comportamento em caso de falha. Escolha a interface depois de definir a transformação, em vez de estender um exemplo funcional de reescrita de URL a uma fase de processamento que nunca recebe.