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，这对我来说大部分都不清楚，因为标题实际包含“Connection：close”，它是否相关？

那么，还有什么进一步的评论吗？

Answer 1

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

RFC 2616 Section 4.4. Message Length：

消息的传输长度是消息体的长度      它出现在信息中;也就是说，在任何转移编码之后      已被应用。当消息中包含消息正文时，      该身体的转移长度由以下之一决定      （按优先顺序排列）：



任何响应消息＆＃34; MUST NOT＆＃34;包括一个消息体（例如    作为1xx，204和304响应以及对HEAD的任何响应    请求）总是在第一个空行后终止    标题字段，不管实体标题字段是否存在    消息。



如果存在Transfer-Encoding标头字段（第14.41节）    除了＆＃34; identity＆＃34;之外还有其他任何值，那么传输长度是    通过使用＆＃34; chunked＆＃34;来定义转移编码（第3.6节），    除非通过关闭连接终止消息。



如果存在Content-Length标头字段（第14.13节），则为其    OCTET中的十进制值表示实体长度和    转发长度。不得发送Content-Length头字段    如果这两个长度不同（即，如果转移编码    标题字段存在）。如果收到包含a的消息    Transfer-Encoding标头字段和Content-Length标头字段，    后者必须被忽略。



如果消息使用媒体类型＆＃34; multipart / byteranges＆＃34;，    转移长度没有另外规定，那么这个自我    分隔媒体类型定义传输长度。这种媒体类型    除非发件人知道收件人可以解析，否则不会使用[M] UST    它;存在于具有多个字节的Range标头的请求中 -    1.1客户端的范围说明符暗示客户端可以解析    multipart / byteranges响应。

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



由服务器关闭连接。（关闭连接    因此，不能用于表示请求正文的结束    不会让服务器发回回复。）

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

1 个答案: