Rails 何时响应“传输编码"与“内容长度"? [英] When does Rails respond with 'transfer-encoding' vs. 'content-length'?

问题描述

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

I'm building an API on Rails version 4.1.7/Nginx that responds to request from an iOS app. We're seeing some weird caching on the client and we think it has something to do with a small difference in the response that Rails is sending back. My questions...

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

1) I want to understand why, for the exact same request (with only the Authorization header value changed), Rails sends back transfer-encoding: chunked sometimes and Content-Length: <number> sometimes? I thought that maybe it had something to do with the response size, but in the example responses whose headers I've pasted below, the data returned in the body is EXACTLY the same.

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

2) Is there a way to force it to use Content-Length? We think that that will fix our caching issues in our iOS app.

响应 #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

推荐答案

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

Both responses are valid according to HTTP 1.1, so you need to fix your client code that it can handle both. It is a bad idea to try to fix the server so that that it behave in a way that it does not trigger a bug in the client. The next version of nginx may behave differently, you users may even have proxies that change the transfer, maybe only when they do roaming and use a different provider.

如果你想在头上做一些指纹识别，ETag-header 可能会帮助你，因为当响应的内容没有改变时，ETag 应该保持不变，而不管传输.

If you want to do some finger-printing on the header, the ETag-header may help you, as the ETag should stay constant when the content of the response is not changed, regardless of the transfer.

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

The server typically sends in chunks when it calls a dynamic page, because it then does not need to create a buffer for the whole page and wait till all of the page is generated.

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

The server often send the response in one go if it has the buffer already, for example because it is in cache or the content is on a file and is not to big. Sending in one go is more efficient, on the other hand, an extra copy of the data to buffer the output needs more memory and is less efficient. So the server may even decide this according to the available memory.

这篇关于Rails 何时响应“传输编码"与“内容长度"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！