正确的分块传输编码格式

Question

我很好奇，与规范相比，分块数据的正确格式是什么，以及Twitter从他们的活动流中返回了什么。

当使用curl尝试从Twitter获取分块流时，curl报告：

~$ curl -v https://stream.twitter.com/1/statuses/sample.json?delimited=length -u ...:...
< HTTP/1.1 200 OK
< Content-Type: application/json
< Transfer-Encoding: chunked
<
1984
{"place":null,"text":...
1984
{"place":null,"text":...
1984
{"place":null,"text":...

我已经编写了一个基于Wikipedia info和HTTP规范的分块数据发射器(本质上是：\r\n\r\n)，我的结果如下：

~$ curl -vN http://localhost:7080/stream
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Transfer-Encoding: chunked
< 
{"foo":{"bar":...
{"foo":{"bar":...
{"foo":{"bar":...

不同之处在于，Twitter似乎将字符串的长度作为块主体的一部分作为整数(与十六进制的值一起包含，该值也必须在那里)，我想确保我没有遗漏什么。推特文档没有提到长度值，它不在他们的examples中，我也没有在规范中看到任何关于它的内容。

Answer 1

如果您的代码没有发出长度信息，那么它显然是不正确的。参见http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.6.1。

Answer 2

RCF2616-19.4.6传输编码简介

A process for decoding the "chunked" transfer-coding (section 3.6) can be represented in pseudo-code as:
   length := 0
   read chunk-size, chunk-extension (if any) and CRLF
   while (chunk-size > 0) {
      read chunk-data and CRLF
      append chunk-data to entity-body
      length := length + chunk-size
      read chunk-size and CRLF
   }
   read entity-header
   while (entity-header not empty) {
      append entity-header to existing header fields
      read entity-header
   }
   Content-Length := length
   Remove "chunked" from Transfer-Encoding

正如RFC所说，块大小不会附加到实体主体。我已经阅读了curl(函数Curl_httpchunk_read)的源代码，并确保它跳过了块大小\r\n，只需将块大小的字节附加到body中即可。

twitter的回复是分块大小的，我想这是因为使用了https，整个数据都是加密的。