没有内容长度作为响应的流式传输
我正在使用 Node.js、Express（和 connect）和 Fluent-ffmpeg。
我们希望通过 http 传输存储在 Amazon S3 上的音频文件。
我们已经完成了所有工作，只是我们想添加一个功能，即通过 ffmpeg 进行流的即时转换。
这工作得很好，问题是有些浏览器在实际获取文件之前会提前检查。
包含 Range 标头的传入请求（我们使用来自 S3 的所有信息回复 206）有一个根本问题：我们需要提前知道文件的内容长度。
我们不知道，因为它正在通过 ffmpeg。
一种解决方案可能是在存储文件时（在特殊标头中）直接在 S3 上写出结果内容长度，但这意味着我们必须经历在上传后进行队列编码的痛苦，只是为了知道将来的大小请求。 这也意味着如果我们改变压缩器或预设，我们必须重新经历这一切，所以这不是一个可行的解决方案。
我们还注意到 Chrome 和 Safari 请求音频标签 src 的方式存在很大差异，但这可能是另一个主题的讨论。
事实是，如果没有适当的内容长度标头来响应，一切似乎都会中断，或者浏览器会陷入无限循环或随意重新启动流。
有想法吗？
I'm using Node.js, Express (and connect), and fluent-ffmpeg.
We want to stream audio files that are stored on Amazon S3 through http.
We have all working, except that we would like to add a feature, the on-the-fly conversion of the stream through ffmpeg.
This is working well, the problem is that some browsers checks in advance before actually getting the file.
Incoming requests containing the Range header, for which we reply with a 206 with all the info from S3, have a fundamental problem: we need to know in advance the content-length of the file.
We don't know that since it is going through ffmpeg.
One solution might be to write out the resulting content-length directly on S3 when storing the file (in a special header), but this means we have to go through the pain of having queues to encode after upload just to know the size for future requests.
It also means that if we change compressor or preset we have to go through all this over again, so it is not a viable solution.
We also noticed big differencies in the way Chrome and Safari request the audio tag src, but this may be discussion for another topic.
Fact is that without a proper content-length header in response everything seems to break or browsers goes in an infinite loop or restart the stream at pleasure.
Ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这似乎对我有用。
如果您能确认它是否也在您的浏览器中给出了预期的结果，那就太好了。
基本上，您告诉浏览器您将使用分块编码进行流式传输。一个问题可能是，某些浏览器不喜欢在不知道总共应该有多少字节的情况下进行流式传输。
This seems to be working for me.
It would be great if you could confirm whether it gives the expect results in your browsers too.
Basically, you tell the browser that you are going to stream using chunked encoding. An issue may be that some browsers do not like streaming without know how much bytes they should expect in total.