5 ms·

WebSockets aren't built on top of HTTP. The initial handshake resembles that of HTTP, but once the connection is upgraded, all compatibility is lost. In other

by slau 10y ago

WebSockets aren't built on top of HTTP. The initial handshake resembles that of HTTP, but once the connection is upgraded, all compatibility is lost. In other words, WebSockets is a TCP protocol that mimicks HTTP during the handshake in order to be left alone by proxies and whatnot.

peterwwillis 10y ago
(edit) WebSockets isn't built on top of HTTP, but it is effectively an extension of HTTP. Not officially of course - then they would have had to get people to agree to an extension, so instead they called it a new protocol. But basically it's an HTTP request that turns into an obfuscated socket.
- toast0 10y ago
  When WebSockets is negotiated on an HTTP connection, it ceases to be an HTTP connection; there is no way back to HTTP without closing the connection. It's kind of like when you start ppp, slip, or slirp on a shell you dialed into -- it's no longer a shell with a virtual terminal, it's changed into an internet connection, and you (usually) can't go back without dropping carrier and reconnecting.
  - peterwwillis 10y ago
    There is really no such thing as an HTTP connection. There are request-response transactions, and these can happen without needing to break down the stateful connection they're transmitted over. Ahem: https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunne... In this mechanism, the client asks an HTTP Proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client. Note that only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection. Both HTTP CONNECT and WS are designed to work over http proxies, both are designed to tunnel arbitrary application data, both use http to initiate a connection, both use http application ports for these connections, and neither of them return to http request-responses once they're set up. But somehow, WS is a separate protocol and stops being http, while HTTP CONNECT is just an HTTP extension and becomes some other application proxied over http. I guess WS is just special.

by slau 10y ago

peterwwillis 10y ago

(edit) WebSockets isn't built on top of HTTP, but it is effectively an extension of HTTP. Not officially of course - then they would have had to get people to agree to an extension, so instead they called it a new protocol. But basically it's an HTTP request that turns into an obfuscated socket.

toast0 10y ago
When WebSockets is negotiated on an HTTP connection, it ceases to be an HTTP connection; there is no way back to HTTP without closing the connection. It's kind of like when you start ppp, slip, or slirp on a shell you dialed into -- it's no longer a shell with a virtual terminal, it's changed into an internet connection, and you (usually) can't go back without dropping carrier and reconnecting.
- peterwwillis 10y ago
  There is really no such thing as an HTTP connection. There are request-response transactions, and these can happen without needing to break down the stateful connection they're transmitted over. Ahem: https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunne... In this mechanism, the client asks an HTTP Proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client. Note that only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection. Both HTTP CONNECT and WS are designed to work over http proxies, both are designed to tunnel arbitrary application data, both use http to initiate a connection, both use http application ports for these connections, and neither of them return to http request-responses once they're set up. But somehow, WS is a separate protocol and stops being http, while HTTP CONNECT is just an HTTP extension and becomes some other application proxied over http. I guess WS is just special.