appengine、urlfetch 和 content-length 标头 [英] appengine, urlfetch, and the content-length header

问题描述

我有一个 Google Appengine 应用程序使用 urllib2 POST 从另一台服务器请求页面.我最近在运行 Apache2 的另一台服务器上启用了 gzip 压缩，Appengine 页面请求开始因键错误而失败，表明内容长度"不在标题中.

I have a Google Appengine app requesting pages from another server using urllib2 POSTs. I recently enabled gzip compression on the other server running Apache2, and the Appengine page requests started failing on key-error, indicating 'content-length' is not in the headers.

我没有在来自 Appengine 的请求中明确声明 gzip 为可接受的编码，但 Appengine 可能正在添加该标头.谷歌搜索没有发现任何明确的迹象表明 Appengine 的 urlfetch 隐式添加了一个标头来接受 gzip 编码.

I am not explicitly declaring gzip as an accepted encoding in my requests from Appengine, but it is possible Appengine is adding that header. Googling has not turned up any clear indication that Appengine's urlfetch implicitly adds a header to accept gzip encoding.

Apache2，如果我没记错的话，在响应被压缩时会省略 content-length 标头，但这不应该影响来自同一服务器的非压缩响应.

Apache2, if I recall correctly, omits content-length headers when the response is compressed, but that should not affect non-compressed responses from the same server.

有没有人知道发生了什么，为什么省略了内容长度标头?

Does anybody have any insight as to what is happening, why the content-length header is being omitted?

推荐答案

根据此线程: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.

这篇关于appengine、urlfetch 和 content-length 标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！