Are multiple responses legal in HTTP?

Question

I'm a bit rusty on nuances of the HTTP protocol and I'm wondering if it can support publish/subscribe directly?

HTTP is a request reponse protocol. So client sends a request and the server sends back a response. In HTTP 1.0 a new connection was made for each request. Now HTTP 1.1 improved on HTTP 1.0 by allowing the client to keep the connection open and make multiple requests.

I realise you can upgrade an HTTP connection to a websocket for fast 2 way communications. What I'm curious about is whether this is strictly necessary?

For example if I request a resource "http://somewhere.com/fetch/me/slowly"

Is the server free to reply directly twice? Such as first with a 202 accepted and then shortly later with the content when it is ready, but without the client sending an additional request first?

i.e.

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

Would it be correct to implement a publish/subscribe service this way? For example:

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

I get the impression that this 'might' work because clients will typically have an event loop watching the connection but is technically wrong (because a client following the protocol need not be implemented that way).

However, if you use chunked transfer encoding this would work.

HTTP/2 seems to allow this as well but I'm not clear whether something changed to make it possible.

I haven't seen much discussion of this in relation to pub/sub so what if anything is wrong with using plain HTTP/1.1 with or without chunked encoding?

If this works why do you need things like RSS or ATOM?

Answer 1

A HTTP request can have multiple 'responses', but the responses all have statuscodes in the 1xx range, such as 102 Processing.

However, these responses are only headers, never bodies.

HTTP/1.1 (like 1.0 before it) is a request/response protocol. Sending a response unsolicited is not allowed. HTTP/2 is a frames protocol which adds server push which allows the server to offer extra data and handle multiple requests in parallel but doesn't change its request/response nature.

It is possible to keep a HTTP connection open and keep sending more data though. Many (audio, video) streaming services will use this.

However, this just looks like a continuous body that keeps on streaming, rather than many multiple HTTP responses.

If this works why do you need things like RSS or ATOM

Because keeping a TCP connection open is not free.