Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-05.txt

[John Tamplin <[e-mail]>]

On Thu, Feb 10, 2011 at 5:59 AM, <[e-mail]> wrote:

> o  Section 4.3 - Continuation frame (opcode=%x0)
>
> It is not clear to me in the document how this frame (opcode=0) is used
> while there's
> FIN bit for fragmentation/defragmentation.
>

The reasonable options are:
 1) define a different frame format for continuation frames that doesn't
have opcodes
 2) use the same opcode as the original frame
 3) use a new opcode

#1 adds complexity and wastes bits for little benefit.  #3 has the benefit
of allowing you to detect the four states of a frame (single-frame message,
initial frame of fragmented message, middle frame of fragmented message,
final frame of fragmented message) if you care, and also provides
opportunity for more error checking.


> Section 4.4 says,
> "..., and terminated by a single frame with the FIN bit set and an opcode
> of 0"
>
> Considering a case where there are text and binary frames that are both
> fragmented
> and alternating over the wire, how can application tell which frame (text
> or binary) the
> last frame with FIN=1 set belongs to?
>
> For example:
> [op=txt, fin=0] [op=bin, fin=0] [op=0, fin=1] <== is this for txt or bin?
>
> Is this kind of multiplexing support intended in the protocol design? If
> the doc explains
> why and how fragmentation is used.
>

No, see 4.4.  Only control frames can be sent in the middle of a fragmented
message (I believe the "open question" line is out of date -- I think the
consensus was that control frames can be injected in the middle of a
fragmented message, otherwise the latency of responding to ping, for
example, would be very long if behind a large message), and control frames
cannot be fragmented.  Multiplexing will be defined as an extension and will
include logical channels.  Even in #2, you would have to maintain the frame
type from the original frame to avoid attacks like [BINARY "invalid UTF8"]
[TEXT/FIN "UTF8"] which could exploit bugs in UTF8 decoders.

o Overall


> As I was reading though, it took some time to find out which feature is for
> which entities
> role as in protocol layering. Ping/pong protocol for example, I am still
> not sure if
> this is done by WebSocket protocol internally or exposed to application.
> Another
> examples would be the extension data filed - who is going to parse it?


The WebSocket implementation will be the one to at least extract the
extension data from the frame, but the interpretation of that data will be
defined by the extension.  It may be processed by the WebSocket layer or the
application depending on the extension.

-- 
John A. Tamplin
Software Engineer (GWT), Google