Re: [hybi] Subprotocol and Control Frames

[Greg Wilkins <[e-mail]>]

On 5 October 2011 07:23, Hapner mark <[e-mail]> wrote:
>
> In my reading of draft 17, I do not find a definition of subprotocol that
> puts any restrictions on the WebSocket extensibility features a subprotocol
> may use.

Mark,

in section 5.8 Extensibility:

   This specification provides opcodes 0x3 through 0x7 and
   0xB through 0xF, the extension data field, and the frame-rsv1, frame-
   rsv2, and frame-rsv3 bits of the frame header for use by extensions.

So while there is no explicit restriction on subprotocols using
opcodes, the only allowance given is to extensions.

> If the sense of the WG is that subprotocols are restricted to use
> only extension data and message format/schema restrictions, this is not
> apparent in the content of this draft.

The specification also describes subprotocols in section 1.3 as

   ... used to indicate what subprotocols (application-level protocols
   layered over the WebSocket protocol) are acceptable to the client.


> It is my observation that there will be a number of WebSocket usecases that
> could benefit from the ability to define usecase-specific control frames to
> mediate message flow. Telling developers to stuff this mediation protocol
> into extension data rather than in control frames does not appear to
> increase security;

Firstly subprotocols can no more use extensions data than they can use
extension opcodes.
They can however use the payload and are free to define arbitrary
message semantics within that payload that may include application
control messages.

The restriction of subprotocols to not use opcodes is not done for
security.  It is done for protocol layering reasons.
The opcode is there to inform the WS implementation (and it's
extensions) how to handle the message.  There is no application
semantics associated with any of the opcodes.  For example the text vs
binary opcodes instructs the implementation if UTF-8 decoding is
required and to which part of the websocket API a message should be
delivered.  There is no semantic restriction imposed by a binary
message, which may actually be a text message, but one for which the
application or subprotocol has taken responsibility for character
encoding.

> rather, it likely decreases security because it
> intermixes control with data which is a fundamentally bad thing for a
> protocol design to do. The two control frames defined by MBWS are fairly simple and are likely
> representative of what other subprotocols would need. It would be far better
> to allow MBWS to properly factor its control and data than force it to put
> control in its data.

Indeed there is a limitation in the current protocol of providing only
a single stream per connection, so there can be no separation of
control/data on a single connection.   However the solution is not to
allow applications to put their control messages into the protocols
control stream, but rather to better support multiple streams - ie
MUX.  For the protocol, it is clear that there are two streams of
frames: data and control,  but there is no reason why this taxonomy
will apply generally to all applications and subprotocols.  There may
be use cases where applications/subprotocols need n streams or control
frames larger than 125 bytes.

The solution is to not see that the protocols control frame mechanism
is somewhat like the applications need for control messages and thus
to attempt to expose the protocols control channel to the application.
 The solution is to allow applications to efficiently create their own
control channels - MUX!


> It is true that TCP does not support application control extension; however,
> HTTP clearly does support this with a very open-ended extension of the HTTP
> header. The WG needs to think carefully about this. I hope there is room to
> resolve this issue in this version of WebSocket.
> It is up to the W3C WebSocket API to insure it provides the functionality
> that both native users of WebSocket and implementors of WebSocket
> subprotocols require. In looking over what is currently defined, this API
> does not yet provide an API sufficient for the later. Possibly later it
> will. I don't believe that the design of WebSocket needs to be restricted by
> the current limitations of this API.

This distinction between extensions and subprotocols has not been made
because of any API limitations.  It has been done for good protocol
layering reasons.

Consider if we open up the control channel to applications, then this
will make the task of creating things like MUX extensions much more
difficult. The mux solution would have to allow for extending control
frames with extension data so that they may be correctly routed to the
right application control channel.  But if a 125 byte application
control frame is sent, then there may not be sufficient room to add
the channel identifier!    Also if control frames are used to
implement MUX flow control, will applications use their application
control frames to attempt to get around this flow control?  We may end
up needing to put flow control on the control channel to limit the
number of application control frames.

Mixing application control frames with protocol control frames is a
far worse "solution" than mixing application control messages with
application data messages.

regards