HTTP响应头有效,没有Transfer-Encoding和Content-Length？

Question

即使if不包含Content-Length或Transfer-Encoding,HTTP响应标头(如下所示)也是合法的吗？

- Http: Response, HTTP/1.1, Status: Ok, URL: /AAA/B.json
  ProtocolVersion: HTTP/1.1
  StatusCode: 200, Ok
  Reason: OK
  Expires:  Fri, 05 Oct 2012 01:41:30 GMT
  Date:  Fri, 05 Oct 2012 01:40:46 GMT
  Vary:  Accept-Encoding
  Accept-Ranges:  bytes
  Cache-Control:  public, max-age=43
  Server:  Noelios-Restlet-Engine/1.1.10
  ContentType:  application/json;charset=UTF-8
  ContentEncoding:  gzip
  Connection:  close
  X-Served-By:  85.111
  HeaderEnd: CRLF

我希望看到Content-Length或Transfer-Encoding,但它们都不存在.

我读了HTTP-RFC,但仍然不确定.

@CodeCaster,我确实阅读了RFC第4.4节,但我仍然不清楚,正如你所看到的,响应头用于返回一个json流,所以:

• 第4.4节,规则1定义不得包含消息体,似乎不适用于我的情况.
• 第4.4节,规则4,对此不确定,但由于我在响应头中没有看到"multipart/byteranges" - 这是否意味着此规则不适用于我？
• 第4.4节规则5,这对我来说大多不清楚,因为标题实际包含"连接:关闭",它是否相关？

那么,还有什么评论吗？

Answer 1

是的，它是有效的。有五种方法可以确定消息长度：

RFC 2616 第 4.4 节。消息长度：

消息的传输长度是消息正文中出现的长度；也就是说，在应用任何传输编码之后。当消息中包含消息正文时，该正文的传输长度由以下之一确定（按优先顺序）：

1. 任何“不得”包含消息主体的响应消息（例如 1xx、204 和 304 响应以及对 HEAD 请求的任何响应）始终以标头字段后的第一个空行终止，无论实体如何消息中存在的标头字段。

2. 如果传输编码头字段（第 14.41 节）存在并且具有除“身份”之外的任何值，则传输长度通过使用“分块”传输编码（第 3.6 节）来定义，除非消息被终止通过关闭连接。

3. 如果存在 Content-Length 头字段（第 14.13 节），则其以 OCTET 表示的十进制值表示实体长度和传输长度。如果这两个长度不同（即，如果存在传输编码头字段），则不得发送内容长度头字段。如果接收到的消息同时带有传输编码头字段和内容长度头字段，则必须忽略后者。

4. 如果消息使用媒体类型“multipart/byteranges”，并且没有另外指定传输长度，则此自定界媒体类型定义传输长度。除非发送者知道接收者可以解析它，否则不能使用此媒体类型；来自 1.1 客户端的具有多个字节范围说明符的 Range 标头的请求中的存在意味着客户端可以解析多部分/字节范围响应。

范围标头可能由不理解 multipart/byteranges 的 1.0 代理转发；在这种情况下，服务器必须使用本节第 1,3 或 5 项中定义的方法来分隔消息。

5. 由服务器关闭连接。（关闭连接不能用于指示请求正文的结束，因为这将使服务器无法发回响应。）