[feature] Push messaging from server to client

Hi all,

based on the work we did on https://www.w3.org/Submission/viwi-protocol/ I want to request adding new functionality which can be implemented with two new VERBS and two new headers.

Use Case: Clients want to subscribe to urls, as topics with all the filtering, paging information etc. being expressed in the url. This would allow services to push information into clients whenever it is considered necessary.

Implementation: As subscriptions are a "convenience" method compared to polling via GET, I propose two new HTTP Verbs

SUB for subscription to url
UNSUB for un-subscribing from url

To control the frequency of updates, we would need additional headers:

subscription-interval:
subscription-updatelimit:

Periodic The optional interval attribute specifies the update frequency in milliseconds for periodic updates, while the optional updatelimit attribute specifies the maximum update rate in milliseconds for ‘on change’ notification. If interval is set, updatelimit is always overruled.

On change If interval is not set, the notification interval is defined ‘on change’ and can be limited by specifying an updatelimit. If an ‘on change’ occours before updatelimit elapsed, an event will be sent as soon as updatelimit elapsed. If there are multiple changes before the next possible update, only the last one know state is sent after updatelimit elapsed.

Summary As this is very close to a regular GET, it would be easy and we could also standardise that per each client-server relation, there would just be a single UDP/IP channel for notifications used and held up. We could also specify that this is a "simplex" connection regarding payload data. as clients would use other HTTP verbs to send data. Each data sent from the server to the client would be exactly the same as a GET response. Very straight forward from my perspective and a valuable extension of the standard for all things "realtime".

All the Headers we replicate in WebSockets today.. puuuffff gone ;) we can just plain HTTP headers...

The viwi/RSI spec would than be just rewrote to hold the interface design rules etc. the entire WebSocket parts would be obsolete.

Also It would than not be relevant anymore wether we transmit JSON (text) or binary content..

Think of it as a GET with multiple responses.. same formats, payloads, everything.. just not req/res but req/res/res/res/res... including all status codes etc.

Re-Auth would also just be another SUB request with a new Token.. super easy ;)

There are a couple of solutions discussed and implemented. As described in the spec I reference to, WebSockets are used, replicating some of the HTTP headers and a topic.

With this proposal, I want to reduce friction. - ¥ Why setup two sockets, if you can handle it via one?

The socket you use for HTTP GET, PUT, POST etc. would have to kept open but could then be used to push information in the other direction.

Think of a multi-repsonse GET request. Super convenient to work with from developers point of view on both ends of the connection. No extra protocol needed, no extra syntax to learn. Just multiple responses to the same GET request, either on an on change or a periodic basis, limited to a certain rate by either the client or the server.

Use-case 1 - chat messages

SUB /messages/

initial response

290 OK

1st data response

200 OK
[
  "foo",
  "bar"
]

2nd data response (100ms later)

200 OK
[
  "foo",
  "bar",
  "boo"
]

etc.

httpwg / http-extensions

[feature] Push messaging from server to client #809