Question

我对与规范相比的分块数据的正确格式以及Twitter从其活动流返回的内容感到好奇。

当使用curl尝试从Twitter获取Chunked流时，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似乎将字符串的长度作为整数的主体的一部分包含在整数中（与Hex中的值一起也必须在那里），我想确保我没有错过什么。 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，只需将其后面的块大小字节附加到主体

twitter用块大小答复，我认为是因为使用https，整个数据都被加密了。

适当的分块传输编码格式

2 个答案: