根据此线程:http://groups.google.com/组/google-appengine-java/browse_thread/thread/5c5f2a7e2d2beadc?pli=1)在 Appengine Java 新闻组中，Google 通常会在 urlfetch 请求上设置Accept-Encoding: gzip"标头，然后在将数据传递给脚本之前解压缩(unzips)输入.

According to this thread: http://groups.google.com/group/google-appengine-java/browse_thread/thread/5c5f2a7e2d2beadc?pli=1) on an Appengine Java newsgroup, Google does generally set the 'Accept-Encoding: gzip' header on urlfetch requests, and then decompresses (ungzips) the input before handing the data to the script.

很明显，Appengine 添加了一个 accept-encoding: gzip 标头，隐式地添加到互联网的请求路径上，并解压缩响应，但不会将内容长度插入到解压缩数据大小的标头中.因此，如果外部服务器将提供 gzipped 响应，则 Appengine 脚本的最终结果(在上述 Appengine 的所有预处理和后处理行为之后)是内容长度标头的丢失.

So apparently, Appengine adds an accept-encoding: gzip header implicitly on the requests way out to the internet, and decompresses the response, but does not insert a content-length into the headers for the decompressed data size. So if the outside server will provide gzipped responses, the net result to the Appengine script (after all the pre- and post- processing behavior by Appengine described above) is the loss of the content-length header.