我正在尝试将音频发送到希望将音频作为分块帖子的网络服务。发送预先录制的文件可以正常工作，但运行下面的代码并不会像看起来那样向服务器发送任何内容。 curl 是否试图将所有内容分成一个块发送？我找不到任何选项，例如要求它每 xxx 个字节分块。
gst-launch-1.0 pulsesrc ! "audio/x-raw,rate=16000,channels=1,format=S16LE" ! fdsink sync=false | \
curl --header "Transfer-Encoding: chunked" --data-binary @- http://...
【问题讨论】：
标签： curl chunked-encoding
如果这对将来的任何人有帮助 - 我试图使用 curl 重现我在基于旧版本 Apache CXF 3.x 的应用程序调用 SOAP API 时看到的问题：使用相同的标头和有效负载，我观察到服务器在第一次 POST（没有收到服务器回复）后默默地从 CXF 连接连接，而 curl 的相同操作会成功。
HTTP 标头是相同的，包括 Transfer-Encoding: chunked 并且 not 具有 Content-Length 标头集。
一个关键区别是 curl 将整个 POST 作为大约 13K 的单个块发送，而 CXF 将其拆分为多个 4K 块。
接收服务器是某种旧的 ASP.NET 服务器，可能使用 IIS 6.x，它似乎默认禁用了分块和/或对它的支持很差。
我发现 curl 中没有用于控制块大小的选项，但是一旦我开始从源代码构建自己的二进制文件（这真的很容易 - 有很多关于如何做的文档），似乎明显的限制确实对分块没有任何影响。
从环境变量设置CURLOPT_BUFFERSIZE 只会影响读取缓冲区大小，但我们正在查看写入数据
所以我尝试先将CURL_MAX_WRITE_SIZE 在include/curl/curl.h 中缩小到4096，当这没有区别时，我尝试在lib/urldata.h 中将UPLOADBUFFER_DEFAULT 和UPLOADBUFFER_MAX 缩小到4096
但似乎这些缓冲区大小对分块没有影响。
最终我发现你可以通过在lib/http.h 中将MAX_INITIAL_POST_SIZE 从(64*1024) 更改为(4*1024) 来设置块大小，然后它将我的POST 有效负载分成~4k 块并重现了与我在CXF 的HttpClient 中看到的相同的问题.
总之：
如果您需要强制 curl 将 POST 数据分解为小于默认 64K 的块，那么您需要编译您自己的版本并相应地设置 MAX_INITIAL_POST_SIZE。
【讨论】：
实际上，gst-plugins-bad 中有一个 curlhttpsink，现在可以使用： gst-launch-1.0 pulsesrc ！ “音频/x-raw，速率=16000，通道=1，格式=S16LE”！ curlhttpsink location=http://...
这样您就不需要手动指定任何块大小，因为这是由接收器处理的。
【讨论】：
curl的命令……它是其他一些应用程序