Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00

[Willy Tarreau <[e-mail]>]

On Mon, Jul 12, 2010 at 12:10:22PM +0200, Anne van Kesteren wrote:
> On Mon, 12 Jul 2010 11:48:41 +0200, gabriel montenegro  
> <[e-mail]> wrote:
> >>Yes, but mostly I'm saying that
> >>the requirements document should not constrain the design to this level  
> >>of detail.
> >
> >[gm] I think it is appropriate, given that we're supposed to be working  
> >on what the charter set out to do:
> >
> >"  The Hypertext-Bidirectional (HyBi) working group will seek
> >  standardization of one approach to maintain bidirectional
> >  communications between the HTTP client, server and intermediate
> >  entities, which will provide more efficiency compared to the current
> >  use of hanging requests.
> >"
> >
> >That seems pretty clear about HTTP usage.
> 
> Not to me. The main reason we are discussing what "HTTP compatible" means  
> and how the "HTTP handshake" ought to look is because someone at IANA  
> thought WebSocket should share a port with HTTP. It has nothing much to do  
> with the charter. And frankly, it seems like things might be much easier  
> if we did not share a port with HTTP.

If it does not share the port, then it will not replace existing protocols !

Also there are good reasons for sharing ports :
  - you can't reasonably assign new well-known ports, since most visitors
    from enterprise networks won't be able to access them for a long time,
    thus limiting adoption.

  - expecting a new address to be assigned for each service is not
    practical for shared hosting providers who manage hundreds or
    thousands of customers on shared equipments, all routed on the HTTP
    Host header only. Clearly those ones will not start assigning a
    dedicated IP to every customer that asks for one just for WebSocket.

  - in many environments there will be a need for Host-based forwarding
    or even cookie-based server stickiness. This is already possible on
    other HTTP-based mechanisms, and will be required for newcomers if
    the intent is to make long-polling disappear.

The fact that HTTP compliance is required might be the problem though.
I'd prefer to see the protocol described as the part after the HTTP
handshake, and simply state that people who want to use it over HTTP
will just have to perform the HTTP handshake first. Check RFC2817, it
explains the same principle for TLS over HTTP. This leaves a large
degree of freedom for implementers, allows for less overhead for those
who don't intend to share a port with HTTP, and allows for higher
accessibility for those who can't proceed differently.

In my opinion, the HTTP handshake should just be a paragraph in
the spec, not 90% of the spec.

Regards,
Willy