HTTP请求的gzip不正确，找不到是谁在做

我们看到一些非常奇怪的HTTP响应，我们不知道是什么做的。 我们有一个应用程序服务器处理JSON请求。 有时候，响应会被gzip返回，但带有不正确的头部，导致浏览器无法正确解释。

问题是间歇性的，随着时间的推移会改变行为。 昨天上午，它似乎失败了50％，事实上，似乎与我们的两个负载平衡服务器之一。 在下午的晚些时候，它只有1000次失败了20次，并没有与应用程序服务器相关联。

这两个应用程序服务器使用mod_wsgi和Django应用程序堆栈运行Apache 2.2。 他们有相同的Apacheconfiguration和源代码树，甚至在Red Hat上安装相同的软件包。 前面有一个硬件负载平衡器，我不知道这个品牌或型号。

Akamai也是食物链的一部分，尽pipe我们移除了Akamai，但仍然存在问题。

• Apache中神秘的GET请求
• 将tomcat6连接到apache2
• 是什么造成了Apache 2.2每秒300个连接的限制？
• 扩展服务器群集设置
• 使用apache日志测量和可视化Web应用程序的性能？

这是一个很好的要求和回应：

* 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": ""} 

这是一个糟糕的：

 * 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 < XN: S < { [data not shown] * Connection #0 to host example.com left intact * Closing connection #0  V -NW RPR QP*.I,)-   A   ̼ Ԣ    T  Z    / 

有两点需要注意：

1. 它有两个内容编docker，浏览器似乎使用第一个。 所以他们看到一个身份编docker和gzip内容，所以他们不能解释响应。

2. 坏的响应有一个额外的“XN：S”头。

也许如果我可以找出中介添加“XN：S”标题的答复，我可以追查到罪魁祸首…