[whatwg] web-apps - TCPConnection

[Ian Hickson]

On Sun, 16 Oct 2005, S. Mike Dierken wrote:
>
> http://whatwg.org/specs/web-apps/current-work/#network
> 
> My only question is - why?

Imagine trying to play a game like Quake implemented in a Web page. You 
need bidirectional communication. Another example would be something like 
an IM or chat client. All the current implementations of that are huge 
hacks that would be much simpler to implement if they could just open a 
TCP connection and send free-form data back and forth.


> It seems bizarre to introduce this section into a Web browsing 
> environment where HTTP is available to define most of the interactions 
> described in this section.

HTTP is a stateless synchronous protocol for resource management. The 
TCPConnection interface is a stateful asynchronous protocol for 
bidirectional realtime communication. They are very different.


> I realize this is just a draft, but there are some odd descriptions - for
> example, the TCPConnection must use port 80 (the port that defines HTTP),
> but later the communication requirements define a completely different and
> new protocol on that port:

It's not intended to use port 80 only; where does it say that? That's an 
error. It is intended to be usable on ports 80, 443, and anything greater 
than 1024. (80 and 443 to attempt to tunnel out of psychotic firewalls, 
and anything greater than 1024 so that you can't talk to things like SMTP 
or FTP servers, something that could allow all kinds of security problems. 
The handshake also attempts to reduce the risk of security issues.)


> "Once a TCP/IP connection to the remote host is established, the user 
> agent must transmit the following sequence of bytes, represented here in 
> hexadecimal form: 0x48 0x65 0x6C 0x6C 0x6F 0x0A This represents the 
> string "Hello" followed by a newline, encoded in UTF-8. "
> 
> This whole section seems somewhat unnecessary. If you are trying to 
> securely establish a connection & then switch to a private/proprieatry 
> protocol, you can use the Upgrade header to transition beyond HTTP once 
> the connection is established: 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42

We don't want to require that authors implement an entire HTTP server just 
to be able to switch to a proprietary protocol. Also, HTTP does not define 
a reliable handshake protocol to prevent bogus data injection into other 
servers of protocols -- for example, HTML forms have already been used to 
inject data into SMTP servers and FTP servers in (successful) attempts at 
distributing spam from third-party computers by sending HTTP packets at 
SMTP and FTP ports. By having a very specific handshake protocol that 
servers must obey before the client will allow arbitrary data out, we 
avoid the possibility of servers getting hijacked in this way.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'