HTTP 中的多重响应是否合法？

Question

我对 HTTP 协议的细微差别有点生疏，我想知道它是否可以直接支持发布/订阅？

HTTP 是一种请求响应协议。所以客户端发送请求，服务器发回响应。在 HTTP 1.0 中，为每个请求建立了一个新连接。现在 HTTP 1.1 改进了 HTTP 1.0，允许客户端保持连接打开并发出多个请求。

我意识到您可以将 HTTP 连接升级到 websocket 以进行快速的 2 路通信。我很好奇的是这是否是绝对必要的？

例如，如果我请求资源“ http://somewhere.com/fetch/me/slowly ”

服务器有空直接回复两次吗？例如首先接受 202，然后在内容准备好后不久接受内容，但没有客户端先发送额外的请求？

IE

Client: GET http://somewhere.com/fetch/me/slowly
Server: 202 "please wait..."
Server: 200 "here's your document"

以这种方式实现发布/订阅服务是否正确？例如：

Client: http://somewhere.com/subscribe
Server: item 1
...
Server: item 2

我的印象是这“可能”有效，因为客户端通常会有一个事件循环来监视连接，但在技术上是错误的（因为不需要以这种方式实现遵循协议的客户端）。

但是，如果您使用分块传输编码，这将起作用。

HTTP/2 似乎也允许这样做，但我不清楚是否进行了更改以使其成为可能。

我还没有看到太多关于 pub/sub 的讨论，所以如果使用带有或不带有分块编码的普通 HTTP/1.1 有什么问题怎么办？

如果这有效，为什么你需要像 RSS 或 ATOM 这样的东西？

Answer 1

一个 HTTP 请求可以有多个“响应”，但响应都具有1xx范围内的状态代码，例如102 Processing。

但是，这些响应只是标题，而不是正文。

HTTP/1.1（就像之前的 1.0）是一个请求/响应协议。不允许发送未经请求的响应。HTTP/2 是一种帧协议，它添加了服务器推送，允许服务器建议提供额外的数据并并行处理多个请求，但不会改变其请求/响应性质。

可以保持 HTTP 连接打开并继续发送更多数据。许多（音频、视频）流媒体服务将使用它。

然而，这看起来只是一个持续流的连续体，而不是许多多个 HTTP 响应。

如果这有效，为什么你需要像 RSS 或 ATOM 这样的东西

因为保持 TCP 连接打开不是免费的。