4 ms·
Don't get it. If you are interested in the low level communications, why wouldn't you simply use a socket and send your own application defined commands over po
by the_me 18y ago
Don't get it. If you are interested in the low level communications, why wouldn't you simply use a socket and send your own application defined commands over port 80?
HTTP exists so that any browser can access any web server, it doesn't re-implement or otherwise allow the usage of TCP/IP.
As a corollary, I don't see why I need to know about your application's communication protocol, let alone adhere to it because it's now a standard.
- mbreese 18y agoWe are talking about bi-directional communications between the client and server. Specifically, server initiated requests to the client. So the major issue that you can overcome with this would be overcoming some NAT/firewall issues. This proposal would be to convert HTTP from being a client making requests to a server to (effectively) a server making / receiving requests from another server. So your browser would also be a (mini) server, handling requests from the main server. This is largely for people that want to use HTTP as a message-passing protocol, but use it in a bi-directional manner between possibly NAT'd hosts.
- tonyg 18y ago"This is largely for people that want to use HTTP as a message-passing protocol, but use it in a bi-directional manner between possibly NAT'd hosts." That is exactly it. You've got it. HTTP makes an almost ideal message passing protocol: it has a rich and battle-tested addressing model; it is asymmetric in a helpful way (really! the response codes are similar to ICMP messages, where the requests are similar to IP datagrams); it is widely supported and deployed; it is content neutral. It doesn't even have to be inefficient ;-) (http://www.lshift.net/blog/2009/02/27/streamlining-http http://www.lshift.net/blog/2009/02/27/streamlining-http)