[whatwg] web-apps - TCPConnection
S. Mike Dierken
mike at dierken.com
Mon Oct 17 20:14:23 PDT 2005
> 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
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
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
> > "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
> > 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
Nobody has suggested requiring an entire server. Two messages is all it
takes. Not only does HTTP scale up well, it scales down too.
More information about the whatwg