[whatwg] web-apps - TCPConnection

> 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.

Received on Monday, 17 October 2005 20:14:23 UTC