[whatwg] web-apps - TCPConnection
mdierken at hotmail.com
Wed Oct 26 20:18:07 PDT 2005
> If the browser had an HTTP daemon built-in,
> would that work?
> No, since you can't guarentee that incoming connections will connect (e.g.
> because you are behind NAT with no port forwarding, a very common case).
If the client initiated the connection, then the roles were reversed, that
would mirror the TCPConnection approach.
> Also, requiring that UAs implement HTTP servers, as opposed
> to just implementing the simple TCPConnection protocol
> described at the moment, seems like a significantly more
> expensive way of solving this problem.
A full (i.e. complex) server wouldn't be necessary, just the protocol
Implementing the protocol for simple use is straightforward, and bringing in
Apache as a library would be one approach.
> > > 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
> Yes, lots of people have. It would be a lot simpler with a
> bidirectional asynchronous text-based messaging protocol, though.
>From my perspective, it would be a lot simpler to re-use a working protocol
(HTTP) rather than start over & re-learn all the mistakes of the past.
> > The DOM Event portion of the specification is very similar & more than
> > sufficient for chat and IM.
> That's one way of receiving messages, but it isn't as good for sending
> them. Using HTTP to send them requires some acrobatics on the server side.
> Using TCPConnection would just mean one process server side.
How is using HTTP going to require acrobatics on the server side? I must be
misunderstanding what you are thinking, because there are dozens of
implementation of HTTP servers.
> > 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.
> That would require that the Web author implement HTTP on his side (or at
> least a simple version of an HTTP server) which seems like undue work.
My opinion is that 'implement HTTP' means 'reading and parse a text stream'
- not undue work, even for a 'Web author'.
> What would the advantage be? We're not connecting to an HTTP server.
> Upgrade makes sense if you are upgrading from HTTP to something, but here
> we're not expecting HTTP to ever be used over the connection.
The point is that since you want to initiate a connection on port 80, then
you should use the protocol assigned to that port. It has specified
mechanisms to upgrade to a proprietary protocol - it doesn't cost a whole
heck of a lot & you wind up being standards compliant.
> > > 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.
> No, because you have to implement correct handling of everything _other_
> than Upgrade: as well, even if it is to return "Not Supported" each time.
> You have to parse headers, etc. Nobody is going to actually bother to
> correctly implement that, and if they don't, what's the point in
> pretending that they do? It would just make matters worse, with obscure
> per-server/client pair bugs for browsers to work around.
Browsers don't need to work around a broken server, regardless of which spec
the server author didn't follow.
More information about the whatwg