4 ms·
That's a naive statement. Take streaming protocols, as an example, and that alone is reason enough for why you shouldn't it over HTTP. HTTP is inherently statel
by aloknnikhil 7y ago
That's a naive statement. Take streaming protocols, as an example, and that alone is reason enough for why you shouldn't it over HTTP. HTTP is inherently stateless. There are many use-cases that are stateful. This leads to high latencies for HTTP streaming since the full state (HTTP headers to tell me who you are and what you want) is sent for every request.
- quotemstr 7y agoHTTP these days (via WebSockets) allows for the creation of stateful connections. My idea is that HTTP will just expand to encompass any remaining non-HTTP use cases. HTTP isn't even coupled to TCO anymore!
- aloknnikhil 7y agoWebsockets use HTTP only for the initial handshake. The rest of the channel uses the Websocket protocol.
- quotemstr 7y agoYes. That protocol is effectively part of HTTP now.
- ivanfon 7y agoThe WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. https://tools.ietf.org/html/rfc6455#section-1.7 https://tools.ietf.org/html/rfc6455#section-1.7
- quotemstr 7y agoEffectively. If you do connection setup, service disambiguation, redirects, and so on with HTTP and switch to a non-HTTP interactive protocol, what you've effectively done is create an HTTP sub-protocol, and I don't care what the document you quoted says.