17

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?

Bruce Adams
  • 4,953
  • 4
  • 48
  • 111

1 Answers1

21

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.

Evert
  • 93,428
  • 18
  • 118
  • 189
  • I think I could accept this answer with a minor tweak. I'll try doing it myself and you can correct as appropriate. – Bruce Adams Nov 30 '18 at 17:30
  • I've attempted the edit but I'm not entirely satisfied with my failure to define a "frames protocol". – Bruce Adams Nov 30 '18 at 17:47
  • @BruceAdams i kinda disagree with your edit and I don't think using HTTP/2 push is an appropriate use for this. HTTP/2 is really just for optimistically populating caches. It should not be used as a pub/sub-like system. – Evert Nov 30 '18 at 18:50
  • Yes. That was badly phrased "but doesn't change its request/response nature" is insufficient. – Bruce Adams Dec 01 '18 at 08:00
  • @Evert "but the responses all have statuscodes in the 1xx range", where do that information came from? I dont disagree, I just want to find some official source. – wair92 Sep 14 '22 at 12:25
  • 1
    @wair92 read the RFCs! – Evert Sep 14 '22 at 15:42
  • What about [103 Early Hints](https://html.spec.whatwg.org/multipage/semantics.html#early-hints)? In the examples given, the subsequent responses have 2xx and 3xx codes. – chharvey Jun 02 '23 at 03:35
  • @chharvey I didn't write this clearly, but there's always one final non-1xx response, which is the _real_ status code. – Evert Jun 02 '23 at 03:44