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