Re: [hybi] WS framing alternative

[Greg Wilkins <gregw at webtide.com>]

Rory Byrne wrote:
> In a further effort to boost our chances of building robust
> WebSocket servers, I would hope that we might consider adding some
> sort of maximum frame length negotiation. Nothing fancy, there
> could be a suitable default maximum, and a 'Max-Frame-Length' header
> which enables a client to negotiate a higher maximum. Maybe something
> like this:
> 
>         GET /demo HTTP/1.1
>         Upgrade: WebSocket
>         Connection: Upgrade
>         Host: example.com
>         Origin: http://example.com
>         WebSocket-Protocol: sample
>         Max-Frame-Length: 2097152
> 
>         HTTP/1.1 101 Web Socket Protocol Handshake
>         Upgrade: WebSocket
>         Connection: Upgrade
>         WebSocket-Origin: http://example.com
>         WebSocket-Location: ws://example.com/demo
>         WebSocket-Protocol: sample
>         Max-Frame-Length: 1048576
> 
> The server would only send a 'Max-Frame-Length' header if it wanted to
> set the maximum to be lower than the client suggested. Any thoughts?


I think having the ability to negotiate such parameters is a good
way to fail fast if a server and client are not compatible (eg
client needs to send larger messages than server is willing to
receive).

But I'm sure that there will be resistance to having such negotiation
as a mandatory part of the protocol.

However, the problem with making this kind of negotiation optional
(and this goes for my earlier examples of a load balancer
communicating SSL info and/or node stickyness), is that the current
WS protocol has no place for meta data to be added in an optional
manner - so that it can be ignored by implementations that don't care.

Ian has previously said that instead of adding headers to the
Upgrade request/response, messages should be injected into the
stream to communicate this meta data.      However, because
there is no way to flag these messages as meta data, simple
implementations are going to try to handle them as messages.

This limitation of no standard meta-data paths, means that it
is nigh impossible to introduce features like multiplexing,
load balancing, fragmentations, HTTP transport etc. as optional
additional specifications built on top of ws.   Because there
is no meta channel, simple implementations will treat everything
as a message and break if there is any new protocol layered
on top.

This is SO simple to fix:

 1) WS should allow arbitrary headers in the upgrade request/response

 2) WS should define a frame type for transport meta data, whose
    content is defined only as Mime (or just mime headers).
    The semantics of these can be left to other protocols built
    on top of WS.

With these 2 simple additions, then we could later develop a
standards that (for example):

 + implement  multi-plexing by negotiated support  in the
   upgrade request/response and then injecting a meta data
   packet, before each data packet, containing the information
   needed to route the subsequent data message.

 + implement standards to send content advisory messages
   that would contain info such as language, content-type etc
   for a connection.   These could be used by implementations
   that wanted to be flexible, or ignored by implementations
   that are sure they know what they are connecting to.

The current proposal is just too nailed down.  There is no where
to insert any optional handling.   The API is wired to the TCP/IP
layer.  The handshake messages are locked down to binary equivalence.
There are spare framing types available - but any suggestions to
allocate that space for meta-data have been rejected.

It appears that the whatwg want layered protocols to be controlled by
the allocation of frame byte values to them and only officially
sanctified extensions will get the nod.   The Whatwg needs to loosen
up and realize  that it should not try to completely control how a
protocol will be used in the wild (eg an not force all servers
to be 100 line perl scripts).  They have to allow it some room to
breath and grow.    They need to allocate some space for some
arbitrary meta data to be used or ignored as implementations see fit.


regards