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

Question

我们看到了一些非常奇怪的 HTTP 响应修改，我们无法弄清楚这是怎么回事。我们有一个处理 JSON 请求的应用服务器。有时，响应以 gzip 格式返回，但包含不正确的标头，导致浏览器无法正确解释它。

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

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

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

这是一个很好的请求和响应：

* 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
< 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?
??/

关于不良反应有两点需要注意：

1. 它有两个 Content-Encoding 标头，浏览器似乎使用第一个。所以他们看到一个身份编码标头和 gzip 压缩的内容，所以他们无法解释响应。

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

也许如果我能找出是什么中介在响应中添加了“XN：S”标题，我就可以找到罪魁祸首......

Answer 1

一些额外的线索

根据http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5：

• Identity默认（身份）编码；不使用任何转换。此内容编码仅在 Accept-Encoding 标头中使用，不应在 Content-Encoding 标头中使用。

Akamai 似乎忽略了一个事实，即服务器可以在其响应中包含此标头，并且在将编码更改为“gzip”时不会删除它。

由于上游服务器“不应该”首先添加标头，这是解决此问题的另一种方法。