RFC 6455, "The WebSocket Protocol", December 2011

Note: This RFC has been updated by RFC 7936, RFC 8307, RFC 8441

Errata ID: 4672
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Anton Dunaev
Date Reported: 2016-04-18

Section 5.6 says:

   Data frames (e.g., non-control frames) are identified by opcodes
   where the most significant bit of the opcode is 0.  Currently defined
   opcodes for data frames include 0x1 (Text), 0x2 (Binary).  Opcodes
   0x3-0x7 are reserved for further non-control frames yet to be
   defined.

   Data frames carry application-layer and/or extension-layer data.  The
   opcode determines the interpretation of the data:

   Text

      The "Payload data" is text data encoded as UTF-8.  Note that a
      particular text frame might include a partial UTF-8 sequence;
      however, the whole message MUST contain valid UTF-8.  Invalid
      UTF-8 in reassembled messages is handled as described in
      Section 8.1.

   Binary

      The "Payload data" is arbitrary binary data whose interpretation
      is solely up to the application layer.

It should say:

   Data frames (i.e., non-control frames) are identified by opcodes
   where the most significant bit of the opcode is 0.  Currently defined
   opcodes for data frames include 0x00 (Continuation), 0x1 (Text) and
   0x2 (Binary).  Opcodes 0x3-0x7 are reserved for further non-control
   frames yet to be defined.

   Data frames carry application-layer and/or extension-layer data.  The
   opcode determines the interpretation of the data:

   Text

      The "Payload data" is text data encoded as UTF-8.  Note that a
      particular text frame might include a partial UTF-8 sequence;
      however, the whole message MUST contain valid UTF-8.  Invalid
      UTF-8 in reassembled messages is handled as described in
      Section 8.1.

   Binary

      The "Payload data" is arbitrary binary data whose interpretation
      is solely up to the application layer.

   Continuation

      These frames MUST be always preceeded by either Text or Binary
      frame with FIN bit clear (See Section 5.2). The "Payload data"
      contains next fragment (See section 5.4) of the message whose
      transmission were opened by the latest Text or Binary frame and
      MUST be interpreted in the same way as the initial fragment of
      the message.

Notes:

For any other opcode defined frames are explicitly listed and described in either Section 5.5 or Section 5.6. But continuation frame is not.

Formally it matches definition of data frame (given in section 5.6) as the most significant bit of its opcode is 0. Logically it should be data frame too. But it is unclear whether there are two categories of frames (data and control) or the Continuation frame represents the third.

One could guess though that Continuation frame is a data frame from the content of the section 5.5.1 stating that "An endpoint MAY delay sending a Close frame until its current message is sent (for instance, if the majority of a fragmented message is already sent, an endpoint MAY send the remaining fragments before sending a Close frame)". This fragment clarifies that Close frame is sent after an endpoint finished message transmission. Thus such interpreation would be consistent with the Section 5.5.1 stating that "The application MUST NOT send any more data frames after sending a Close frame".

Report New Errata