0

与规范相比，我很好奇分块数据的正确格式以及 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":...

我已经根据维基百科信息和 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 似乎将字符串的长度作为整数的一部分作为块体的一部分（连同必须存在的十六进制值一起），我想确保我是没有遗漏什么。Twitter 文档没有提到长度值，不在他们的示例中，我在规范中也没有看到任何关于它的内容。

4

2 回答 2

0

If your code does not emit length information that it is clearly incorrect. See http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.6.1.

于 2012-01-31T08:33:13.380 回答
0

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回复是chunk-size，我想是因为使用了https，整个数据都是加密的。

于 2019-08-08T07:32:35.620 回答