We're seeing some very strange mangling of HTTP responses, and we can't figure out what is doing it. We have an app server handling JSON requests. Occasionally, the response is returned gzipped, but with incorrect headers that prevent the browser from interpreting it correctly.

The problem is intermittent, and changes behavior over time. Yesterday morning it seemed to fail 50% of the time, and in fact, seemed tied to one of our two load-balanced servers. Later in the afternoon, it was failing only 20 times out of 1000, and didn't correlate with an app server.

The two app servers are running Apache 2.2 with mod_wsgi and a Django app stack. They have identical Apache configs and source trees, and even identical packages installed on Red Hat. There's a hardware load balancer in front, I don't know the make or model.

Akamai is also part of the food chain, though we removed Akamai and still had the problem.

3 Answers
3

identity The default (identity)
encoding; the use of no
transformation whatsoever. This
content-coding is used only in the
Accept- Encoding header, and SHOULD
NOT be used in the Content-Encoding
header.

Akamai seems to be ignoring the fact that a server could include this header in their response and is not removing it when the change the encoding to "gzip".

Since the upstream server "should" not be adding the header in the first place, that is another way to fix this problem.

We got confirmation from Akamai that they are gzipping the response and adding a "Content-Encoding: gzip" without first removing the existing Content-Encoding. We've identified the place in our code that adds the identity header, and removed it. Still no word on what "X-N:S" means! :)
–
Ned BatchelderApr 22 '10 at 11:55

Any reverse proxy in the request path? What modules are loaded in apache? What does the apache config look like? If you disable mod_deflate, does it still occur? Is a php script processing your json output that uses ob_start and handles its own compression?