ruby-on-rails – Rails什么时候响应’transfer-encoding’和’content-length’？

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

1)我想理解为什么,对于完全相同的请求(仅更改Authorization标头值),Rails发送回传输编码：有时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,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

解决方法

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

如果你想在标题上做一些指纹打印,那么ETag标题可能对你有所帮助,因为当响应的内容没有改变时ETag应该保持不变,无论转移如何.

服务器通常在调用动态页面时发送块,因为它不需要为整个页面创建缓冲区并等待直到生成所有页面.

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

原文地址：https://www.jb51.cc/ruby/274092.html