Hello,<br><br>We've had a number of discussions in the #whatwg channel thus far about the TCPConnection specification in section 6, and the consesus is that there is utility in an asynchronous, bi-directional communication mechanism, but the current proposal has a number of issues that need to be resolved.<br>
<br>There are a list of requirements for the protocol:<br><br><Hixie> basically my main requirements are that: <br>HIXIE.1) there be the ability for one process to have a full-duplex communication channel to the script running in the web page<br>
HIXIE.2) the server-side be implementable in a fully conformant way in just a few lines of perl without support libraries<br>HIXIE.3) that it be safe from abuse (e.g. can't connect to smtp servers)<br>HIXIE.4) that it work from within fascist firewalls<br>
<br><br>There are some issues with the specification as it stands:<br>-----------<br><othermaciej> my two problems with it are: (1) it uses port/host addressing instead of URI addressing, which is a poor fit for the Web model<br>
<othermaciej> (2) it's bad to send non-http over the assigned ports for http and https<br><othermaciej> (3) I am worried that connection to arbitrary ports could lead to security issues, although Hixie tried hard to avoid them<br>
----------<br><br>The complete list from multiple discussions, I believe, is:<br>ISSUE.1) lack of URI addressing<br>ISSUE.2) sending non-http(s) over http(s) ports<br>ISSUE.3) inability to traverse forward proxies<br>ISSUE.4) lack of cross-domain access control<br>
ISSUE.5) DNS rebinding security holes<br>ISSUE.6) lack of load balancing integration<br>ISSUE.7) lack of authentication integration<br>ISSUE.8) virtual hosting with secure communication (no Host header, and even if there was, there's no way to indicate this header *before* the secure handshake)<br>
<br>I propose that we <br>PROPOSAL.1) change the initial handshake of the protocol to be HTTP based to leverage existing solutions to these problems.<br>PROPOSAL.2) modify the API to use URIs instead of port/host pairs<br>
<br>I believe that the HTTP/1.1 OPTIONS method, Upgrade header, and "101 Switching Protocols" response is the best avenue to take because these parts of HTTP were specifically designed to: (1) See if the server can speak the new protocol (2) switch the protocol mid-stream.<br>
<br>How the changes solve the problems<br>=================================<br>ISSUE.1) We added URI addressing<br>ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.<br>ISSUE.3) We can send a CONNECT to the proxy, thus eliminating this problem.<br>
ISSUE.4) We can use the Access-Control header to solve this problem.<br>ISSUE.5) The Host header solves this problem<br>ISSUE.6) Many load balancers use cookies or urls. Using HTTP allows both cookies and urls, so we can integrate with existing HTTP load balancers.<br>
ISSUE.7) Cookies allow standard authentication mechansisms to be applied to the TCPConnection<br>ISSUE.8) We can follow RFC 2817 for TLS upgrading mid stream, <br><br><br>Examples<br>========<br><br>Normal Handshake<br>----------------<br>
In javascript on a page served from the domain "<a href="http://example.com">example.com</a>", the following call is issued:<br><br>tcp  = new TCPConnection("<a href="http://example.com/some/url">http://example.com/some/url</a>") <br>
<br>C:<br>OPTIONS /some/url HTTP/1.1\r\n<br>Host: <a href="http://example.com">example.com</a>\r\n<br>Upgrade: TCPConnection/1.0\r\n<br>Connection: Upgrade\r\n<br>\r\n<br>S:<br>HTTP/1.1 101 Switching Protocols\r\n<br>Connection: Upgrade\r\n<br>
Upgrade: TCPConnection/1.0\r\n<br>\r\n<br><br>C, S:<br><br>[ Bi-directional communication ]<br><br><br>Secure Handshake <br>----------------<br>In javascript on a page served from the domain "<a href="http://example.com">example.com</a>", the following call is issued:<br>
<br>tcp  = new TCPConnection("<a href="https://example.com/some/url">https://example.com/some/url</a>") <br><br>C, S (port 443):<br>[ SSL handshake ]<br>C:<br>OPTIONS /some/url HTTP/1.1\r\n<br>Host: <a href="http://example.com">example.com</a>\r\n<br>
Upgrade: TCPConnection/1.0\r\n<br>Connection: Upgrade\r\n<br>\r\n<br>S:<br>HTTP/1.1 101 Switching Protocols\r\n<br>Connection: Upgrade\r\n<br>Upgrade: TCPConnection/1.0\r\n<br>\r\n<br>C, S:<br>[ Bi-directional communication ]<br>
<br><br>Cross-domain Access Controlled Handshake<br>----------------------------------------<br>In javascript on a page served from the domain "<a href="http://example.com">example.com</a>", the following call is issued:<br>
<br>tcp  = new TCPConnection("<a href="http://www.example.com/some/url">http://www.example.com/some/url</a>") <br><br>C:<br>OPTIONS /some/url HTTP/1.1\r\n<br>Host: <a href="http://www.example.com">www.example.com</a>\r\n<br>
Upgrade: TCPConnection/1.0\r\n<br>Connection: Upgrade\r\n<br>\r\n<br>S:<br>HTTP/1.1 101 Switching Protocols\r\n<br>Connection: Upgrade\r\n<br>Upgrade: TCPConnection/1.0\r\n<br>Access-Control: allow <<a href="http://example.com">example.com</a>>\r\n<br>
\r\n<br><br>C, S:<br>[ Bi-directional communication ]<br><br><br>Handshake Through a Forward Proxy (with Proxy Authentication)<br>-------------------------------------------------------------<br>In javascript from a page served in the domain "<a href="http://example.com">example.com</a>", and the browser is behind a forward proxy, the following call is issued:<br>
<br>tcp  = new TCPConnection("<a href="http://example.com/some/url">http://example.com/some/url</a>") <br><br>C:<br>CONNECT <a href="http://example.com:80">example.com:80</a> HTTP/1.1\r\n<br>Proxy-authorization: basic aGVsbG86d29ybGQ=\r\n<br>
\r\n<br>OPTIONS /some/url HTTP/1.1\r\n<br>Host: <a href="http://example.com">example.com</a>\r\n<br>Upgrade: TCPConnection/1.0\r\n<br>Connection: Upgrade\r\n<br>\r\n<br>S:<br>HTTP/1.1 101 Switching Protocols\r\n<br>Connection: Upgrade\r\n<br>
Upgrade: TCPConnection/1.0\r\n<br>\r\n<br>C, S:<br>[ Bi-directional communication ]<br><br><br>TLS Upgrade<br>-----------<br><br>A potential server-side requirement of TCPConnection is virtual hosting TCPConnection servers by domain while allowing secure communication. RFC 2817 specifies how to do TLS upgrades over HTTP so as to allow the initial Host header to be read by the server before the secure channel is created. We can use the same strategy with the TCPConnection protocol:<br>
<br>C:<br>OPTIONS /some/url HTTP/1.1\r\n<br>Host: <a href="http://example.com">example.com</a>\r\n<br>Upgrade: TLS/1.0\r\n<br>Connection: Upgrade\r\n<br>\r\n<br>S:<br>HTTP/1.1 101 Switching Protocols\r\n<br>Connection: Upgrade\r\n<br>
Upgrade: TLS/1.0, HTTP/1.1\r\n<br>\r\n<br>C:<br>OPTIONS /some/url HTTP/1.1\r\n<br>Host: <a href="http://example.com">example.com</a>\r\n<br>Upgrade: TCPConnection/1.0\r\n<br>Connection: Upgrade\r\n<br>\r\n<br>S:<br>HTTP/1.1 101 Switching Protocols\r\n<br>
Connection: Upgrade\r\n<br>Upgrade: TCPConnection/1.0\r\n<br>\r\n<br>C, S:<br>[ Secure Handshake ]<br>C, S:<br>[ Bi-directional communication ]<br><br><br>Conclusion<br>==========<br>This proposal fits within the original requirements.<br>
<br>HIXIE.1) We've provided full-duplex communication in the browser<br>HIXIE.2) Its a single line of perl code to parse the http headers, and another to make sure the proper headers exist<br>HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is going to send back the appropriate handshake response.<br>
HIXIE.4) TCPConnection will be able to navigate forward proxies and firewalls due to our use of CONNECT.<br><br><br><br>-Michael Carter<br><br>