渐进式 JPEG 是否需要分块传输编码？答案

【问题标题】：Does progressive JPEG require chunked transfer encoding?渐进式 JPEG 是否需要分块传输编码？
【发布时间】：2018-04-04 05:14:41
【问题描述】：

我一直在研究如何通过 HTTP 实现 API，以允许对其返回的资源进行在线处理。例如，该资源可以是渐进式 JPEG。在阅读渐进式 JPEG 以及它们如何在浏览器中呈现时，我从未看到任何提及需要分块传输编码才能工作的内容。如果我理解正确的话，我看不到在不使用分块传输编码的情况下完全下载前如何渲染渐进式 JPEG。这是正确的吗？

编辑：为了澄清为什么我认为如果您不使用分块编码来获取渐进式 JPEG 时需要分块编码，那么发送 JPEG GET 请求的浏览器或其他应用程序不会被传递 JPEG 资源，直到它被完全接受了。另一方面，使用分块编码，当 JPEG 的每个块进入时，应用程序（浏览器或其他）可以对接收到的 JPEG 部分进行渲染或执行任何操作，而不是在完整的 JPEG 之前没有任何处理已下载。

【问题讨论】：

我不明白你为什么需要分块编码。你能详细说明一下吗？
@JulianReschke 我试图在 OP 的底部澄清我的想法。

标签： http web

【解决方案1】：

发送 JPEG GET 请求的浏览器或其他应用程序在 JPEG 资源被完全接收之前不会被传递

那不是真的。浏览器可以在下载完成之前访问他们正在下载的资源。

最后，它全部通过套接字接收，适当的抽象层让应用程序代码在数据包中从该套接字“流式传输”字节。

【讨论】：

我了解您是否使用原始套接字，但这在应用层看起来不像 HTTP。那么分块编码的意义何在？
浏览器穿过 OSI 模型的多个层，没有人禁止这样做。如果浏览器的编程模型只处理完整的 HTTP 响应，它将如何显示下载进度条？至于为什么要使用chunked，见What is the advantage to use chunked encoding?。
是的，我刚刚阅读了this，我意识到我想错了。我对 HTTP 不支持“流”的概念感到困惑，并误解了分块编码的区别/好处。