Re: [hybi] Web sockets and existing HTTP stacks

[Justin Erenkrantz <[e-mail]>]

On Sun, Jan 31, 2010 at 1:22 AM, Ian Hickson <[e-mail]> wrote:
> On the server side, if it's a Web Socket server, then HTTP is irrelevant,
> and again, the extra requirements don't matter. It can just send the Web
> Socket response (which happens to look like HTTP, but that's mostly just
> for consistency with the request). If it's an HTTP server, then Web Socket
> doesn't apply.

Given that the drafts mandate that WebSocket share a port with HTTP,
it is simply not possible to know ahead of time what the incoming
connections are going to be - unless the deployment uses separate IPs
which is the end result of these rules.

However, no reasonable deployment is going to give separate IPs to WS
versus HTTP - so, server-side implementors are left with two choices:
in the case of Jetty, we've seen them go through a whole bunch of code
contortions to implement the strict conformance rules or, what would
have to happen with httpd (because the hacks required would simply be
vetoed and it goes against the whole async server philosophy) - just
ignore them altogether.  Neither places WS on an immediate
good-feeling footing with server-side developers.

Since you brought up your employer and their "market share", I'm very
very willing to bet Google isn't going to use duplicate IP ranges just
for WS vs HTTP either.  They would have to teach their custom
front-ends how to share and route WS *and* HTTP requests as well over
the same port.  So, your colleagues are going to run into this issue
as well.  Perhaps out of courtesy, they went through the same hell
that Jetty went through - but, again, I can't go back to
[e-mail] with a straight face and hack up the overall
architecture just for this non-feature.  The conformance that is
apparently so important would be sacrificed from day one.

As such, the draft should really make it as painless as possible to
share ports.  Either drop the port 80 requirement or drop the overly
strict conformance requirements: you simply can't have it both ways
and expect any serious buy-in from server developers.  (And, really,
altering ports isn't much better, but at least it's philosophically
cleaner.)  I realize that most client devs don't care about this for
the reasons Maciej pointed out (alas, the Serf client framework *does*
care much for the same reasons as httpd - but it obviously doesn't
have the market share of WHATWG's participants - so I don't expect
anyone to care), but this is such a ridiculously large pain point for
servers that is being constantly belittled by the person in charge of
the drafts that it makes me question even continuing to bother
providing feedback at all.  -- justin