[whatwg] web-apps - TCPConnection

[S. Mike Dierken]

> 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. 
Okay. Outbound messages are obviously not a problem. Accepting unsolicited
inbound messages isn't feasible (& the unsolicited part is an invitation to
spam). Having the client initiate the connection & then receiving/responding
to inbound requests is what it sounds like you would need.
If the browser had an HTTP daemon built-in, would that work? 

> 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.
I've implemented IM and chat applications with just HTTP, HTML and
Javascript. In a browser. Without plugins. The DOM Event portion of the
specification is very similar & more than sufficient for chat and IM.

> 
> 
> > 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.)
I misread the specification - I thought it restricted usage to just port
80/etc.
It's unfortunate that port 80 would be needed to 'tunnel out', but I realize
that's the situation most people are in. But I really recommend that a port
80 outbound tunnel use the protocol assigned to that port - via the HTTP
Upgrade header.

> 
> 
> > "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.
Nobody has suggested requiring an entire server. Two messages is all it
takes. Not only does HTTP scale up well, it scales down too.