Rails 何时响应“传输编码”与“内容长度”？答案

【问题标题】：When does Rails respond with 'transfer-encoding' vs. 'content-length'?Rails 何时响应“传输编码”与“内容长度”？
【发布时间】：2015-05-20 16:28:41
【问题描述】：

我正在 Rails 版本 4.1.7/Nginx 上构建一个 API，用于响应来自 iOS 应用程序的请求。我们在客户端上看到了一些奇怪的缓存，我们认为这与 Rails 发回的响应的微小差异有关。我的问题...

1) 我想了解为什么对于完全相同的请求（仅更改 Authorization 标头值），Rails 有时会发回 transfer-encoding: chunked 而有时会发回 Content-Length: <number>？我认为这可能与响应大小有关，但在下面我粘贴标题的示例响应中，正文中返回的数据完全相同。

2) 有没有办法强制它使用Content-Length？我们认为这将解决我们在 iOS 应用中的缓存问题。

响应 #1

HTTP/1.1 200 OK
Cache-Control: max-age=0, private, must-revalidate
Content-Type: application/json; charset=utf-8
Date: Wed, 18 Mar 2015 00:59:31 GMT
ETag: "86f277ea63295460d4f3bed9a073eaa2"
Server: nginx/1.6.2
Status: 200 OK
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: dd36f139-1986-4da6-9645-4438d41e74b0
X-Runtime: 0.123865
X-XSS-Protection: 1; mode=block
transfer-encoding: chunked
Connection: keep-alive

请求 #2

HTTP/1.1 200 OK
Cache-Control: max-age=0, private, must-revalidate
Content-Type: application/json; charset=utf-8
Date: Wed, 18 Mar 2015 00:59:36 GMT
ETag: "86f277ea63295460d4f3bed9a073eaa2"
Server: nginx/1.6.2
Status: 200 OK
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 0cfd7705-157b-41b5-aa36-739bc6f8302e
X-Runtime: 0.092672
X-XSS-Protection: 1; mode=block
Content-Length: 2234
Connection: keep-alive

【问题讨论】：

Rails 发回了第二个响应，还是 nginx 发回了？也就是nginx是自己做缓存的吗？
@MichaelHampton 嗯...我会调查并报告...

标签： ruby-on-rails nginx chunked-encoding content-length

【解决方案1】：

根据 HTTP 1.1，这两个响应都是有效的，因此您需要修复可以处理这两个响应的客户端代码。尝试修复服务器以使其行为方式不会触发客户端中的错误是一个坏主意。下一个 nginx 版本的行为可能会有所不同，您的用户甚至可能有更改传输的代理，也许只有当他们漫游并使用不同的提供商时。

如果您想在标头上做一些指纹，ETag-header 可能会帮助您，因为无论传输如何，当响应的内容没有改变时，ETag 应该保持不变。

服务器通常在调用动态页面时以块的形式发送，因为它不需要为整个页面创建缓冲区并等待所有页面生成。

如果服务器已经有缓冲区，服务器通常会一次性发送响应，例如因为它在缓存中或内容在文件上并且不是很大。一次性发送效率更高，另一方面，用于缓冲输出的数据的额外副本需要更多内存并且效率较低。所以服务器甚至可以根据可用内存来决定。

【讨论】：