Estamos vendo uma confusão muito estranha de respostas HTTP e não conseguimos descobrir o que está fazendo isso. Temos um servidor de aplicativos gerenciando solicitações JSON. Ocasionalmente, a resposta é retornada pelo gzip, mas com cabeçalhos incorretos que impedem o navegador de interpretá-lo corretamente.
O problema é intermitente e altera o comportamento ao longo do tempo. Ontem de manhã, pareceu falhar 50% do tempo e, na verdade, parecia ligado a um dos nossos dois servidores com balanceamento de carga. No final da tarde, ele estava falhando apenas 20 vezes em 1000 e não se correlacionava com um servidor de aplicativos.
Os dois servidores de aplicativos estão executando o Apache 2.2 com o mod_wsgi e uma pilha de aplicativos do Django. Eles têm configurações e árvores de origem idênticas do Apache, e até pacotes idênticos instalados no Red Hat. Há um balanceador de carga de hardware na frente, não sei a marca ou modelo.
Akamai também faz parte da cadeia alimentar, embora tenhamos removido a Akamai e ainda tivesse o problema.
Aqui está uma boa solicitação e resposta:
* Connected to example.com (97.7.79.129) port 80 (#0)
> POST /claim/ HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: example.com
> Accept: */*
> Referer: http://example.com/apps/
> Accept-Encoding: gzip,deflate
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
} [data not shown]
< HTTP/1.1 200 OK
< Server: Apache/2
< Content-Language: en-us
< Content-Encoding: identity
< Content-Length: 47
< Content-Type: application/x-javascript
< Connection: keep-alive
< Vary: Accept-Encoding
<
{ [data not shown]
* Connection #0 to host example.com left intact
* Closing connection #0
{"msg": "", "status": "OK", "printer_name": ""}
E aqui está um mau:
* Connected to example.com (97.7.79.129) port 80 (#0)
> POST /claim/ HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: example.com
> Accept: */*
> Referer: http://example.com/apps/
> Accept-Encoding: gzip,deflate
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
} [data not shown]
< HTTP/1.1 200 OK
< Server: Apache/2
< Content-Language: en-us
< Content-Encoding: identity
< Content-Type: application/x-javascript
< Content-Encoding: gzip
< Content-Length: 59
< Connection: keep-alive
< Vary: Accept-Encoding
< X-N: S
<
{ [data not shown]
* Connection #0 to host example.com left intact
* Closing connection #0
�V�-NW�RPR�QP*.I,)-���A���̼�Ԣ����T��Z�
��/
Existem duas coisas a notar sobre a má resposta:
-
Ele tem dois cabeçalhos Content-Encoding e os navegadores parecem usar o primeiro. Então, eles veem um cabeçalho de codificação de identidade e conteúdo compactado com gzip, para que não possam interpretar a resposta.
-
A resposta ruim tem um cabeçalho extra "X-N: S".
Talvez se eu pudesse descobrir o que o intermediário adiciona cabeçalhos "X-N: S" às respostas, eu poderia rastrear o culpado ...