compactação HTTP no IIS 6.0 causando problemas com determinados usuários

Question

Recebemos algumas chamadas esporádicas de clientes (menos de 0,1% de nossos usuários) queixam-se de não conseguir acessar o site da minha empresa - elas recebem uma página em branco (se usarem o IE) ou "Content Encoding" Erro "que diz que a página usa uma forma de compactação inválida ou sem suporte (se usar o FireFox).

A suspeita atual é que quando uma solicitação de navegador HTTP 1.1 chega por meio de um proxy HTTP 1.0, estamos enviando de volta a solicitação de navegador HTTP 1.1 compactada, que de alguma forma está sendo desconfigurada pelo proxy HTTP 1.0.

O site é um back end do Tomcat 4.2.2 com um front-end do IIS 6.0 com GZIP e DEFLATE habilitados nos servidores IIS.

Alguém já encontrou esse tipo de erro antes? Existe uma correção recomendada para evitar quebrar implementações de proxy mais antigas?

Edit: Podemos replicar o problema com uma configuração padrão do squid-2.5, no entanto versões mais recentes do squid parecem funcionar muito bem.

    

Answer 1

Ok, acho que descobrimos ...

No lado do cliente, o Squid 2.5 e anteriores não entendem "Transfer-encoding: chunked", então ele entrega cada parte como o pedido do cliente inteiro. Como é apenas uma parte de toda a solicitação compactada, são dados inválidos e não podem ser lidos pelo navegador. (Não tenho certeza se isso é um problema com outros proxies)

No lado do servidor, o IIS sempre envia codificação em partes para Compactação dinâmica (já que o IIS não armazena em cache as respostas do aplicativo, ele precisa compactar cada resposta em tempo real, daí a codificação em partes).

A única maneira que podemos pensar em consertar isso é desabilitar completamente a compactação para clientes HTTP 1.0 e apenas compactar para respostas HTTP 1.1. A desvantagem é que qualquer pessoa por trás de um proxy que envia solicitações de 1.0 não recebe dados compactados e o site carregará 0,5 a 1 segundo mais lentamente para esses usuários.

Alterações feitas no arquivo metabase.xml:

<IIsCompressionSchemes            Location ="/LM/W3SVC/Filters/Compression/Parameters"
...
HcDoOnDemandCompression="TRUE"
HcNoCompressionForHttp10="TRUE"
...
</IIsCompressionSchemes>

Se alguém tiver uma solução melhor, informe-nos!

    

Answer 2

Se isso for reproduzível, começarei examinando os cabeçalhos de resposta enviados ao cliente para garantir que haja um proxy 1.0 em algum lugar no fluxo de solicitação / resposta, conforme indicado no cabeçalho Via: response. Se não, então as chances são de que você está latindo na árvore errada. Os proxies devem inserir esse cabeçalho e o protocolo que eles usam em ambas as direções do fluxo de solicitação / resposta.