httppublish-subscribechunked-encoding

Are multiple responses legal in HTTP?

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?

Solution

  • A HTTP request can have multiple 'responses', but all responses except the final 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.