draft-ietf-hybi-thewebsocketprotocol-16.txt   draft-ietf-hybi-thewebsocketprotocol-17.txt 
HyBi Working Group I. Fette HyBi Working Group I. Fette
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Melnikov
Expires: March 30, 2012 Isode Ltd Expires: April 2, 2012 Isode Ltd
September 27, 2011 September 30, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-16 draft-ietf-hybi-thewebsocketprotocol-17
Abstract Abstract
The WebSocket protocol enables two-way communication between a client The WebSocket protocol enables two-way communication between a client
running untrusted code running in a controlled environment to a running untrusted code running in a controlled environment to a
remote host that has opted-in to communications from that code. The remote host that has opted-in to communications from that code. The
security model used for this is the Origin-based security model security model used for this is the Origin-based security model
commonly used by Web browsers. The protocol consists of an opening commonly used by Web browsers. The protocol consists of an opening
handshake followed by basic message framing, layered over TCP. The handshake followed by basic message framing, layered over TCP. The
goal of this technology is to provide a mechanism for browser-based goal of this technology is to provide a mechanism for browser-based
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2012. This Internet-Draft will expire on April 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 17 4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Client Requirements . . . . . . . . . . . . . . . . . . . 17 4.1. Client Requirements . . . . . . . . . . . . . . . . . . . 17
4.2. Server-side Requirements . . . . . . . . . . . . . . . . . 22 4.2. Server-side Requirements . . . . . . . . . . . . . . . . . 22
4.2.1. Reading the Client's Opening Handshake . . . . . . . . 23 4.2.1. Reading the Client's Opening Handshake . . . . . . . . 23
4.2.2. Sending the Server's Opening Handshake . . . . . . . . 24 4.2.2. Sending the Server's Opening Handshake . . . . . . . . 24
4.3. Collected ABNF for new header fields used in handshake . . 27 4.3. Collected ABNF for new header fields used in handshake . . 27
4.4. Supporting multiple versions of WebSocket protocol . . . . 28 4.4. Supporting multiple versions of WebSocket protocol . . . . 28
5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 30 5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 30 5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 30
5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 34 5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 35
5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 35 5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 36
5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 37 5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 38
5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 38 5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 39 5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 40
5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 41 5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 41
6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 42 6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 42
6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 42 6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 42
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 44 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 44
7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 44 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 44 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 44
7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 44 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 44
7.1.3. The WebSocket Closing Handshake is Started . . . . . . 44 7.1.3. The WebSocket Closing Handshake is Started . . . . . . 44
skipping to change at page 30, line 38 skipping to change at page 30, line 38
A data frame MAY be transmitted by either the client or the server at A data frame MAY be transmitted by either the client or the server at
any time after opening handshake completion and before that endpoint any time after opening handshake completion and before that endpoint
has sent a close frame (Section 5.5.1). has sent a close frame (Section 5.5.1).
5.2. Base Framing Protocol 5.2. Base Framing Protocol
This wire format for the data transfer part is described by the ABNF This wire format for the data transfer part is described by the ABNF
[RFC5234] given in detail in this section. (Note that unlike in [RFC5234] given in detail in this section. (Note that unlike in
other sections of this document the ABNF in this section is operating other sections of this document the ABNF in this section is operating
on groups of bits. When encoded on the wire the most significant bit on groups of bits. The length of each group of bits is indicated in
is the leftmost in the ABNF). A high level overview of the framing a comment. When encoded on the wire the most significant bit is the
is given in the following figure. In a case of conflict between the leftmost in the ABNF). A high level overview of the framing is given
figure below and the ABNF specified later in this section, the ABNF in the following figure. In a case of conflict between the figure
version should be considered to be more authoritative. below and the ABNF specified later in this section, the figure is
authoritative.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+ +-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length | |F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/63) | |I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) | |N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | | | |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 | | Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+ + - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 | | |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data | | Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - + +-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... : : Payload Data continued ... :
skipping to change at page 33, line 14 skipping to change at page 33, line 14
length. length.
Application data: y bytes Application data: y bytes
Arbitrary application data, taking up the remainder of the frame Arbitrary application data, taking up the remainder of the frame
after any extension data. The length of the application data is after any extension data. The length of the application data is
equal to the payload length minus the length of the extension equal to the payload length minus the length of the extension
data. data.
The base framing protocol is formally defined by the following ABNF The base framing protocol is formally defined by the following ABNF
[RFC5234]: [RFC5234]. It is important to note that the representation of this
data is binary, not ASCII characters. As such, a field with a length
of 1 bit that takes values %x0 / %x1 is represented as a single bit
whose value is 0 or 1, not a full byte (octet) that stands for the
characters "0" or "1" in the ASCII encoding. A field with a length
of 4 bits with values between %x0-F again is represented by 4 bits,
again NOT by an ASCII character or full byte (octet) with these
values. [RFC5234] does not specify a character encoding - " Rules
resolve into a string of terminal values, sometimes called
characters. In ABNF, a character is merely a non-negative integer.
In certain contexts, a specific mapping (encoding) of values into a
character set (such as ASCII) will be specified." Here, the
specified encoding is a binary encoding where each terminal value is
encoded in the specified number of bits, which varies for each field.
ws-frame = frame-fin ws-frame = frame-fin ; 1 bit in length
frame-rsv1 frame-rsv1 ; 1 bit in length
frame-rsv2 frame-rsv2 ; 1 bit in length
frame-rsv3 frame-rsv3 ; 1 bit in length
frame-opcode frame-opcode ; 4 bits in length
frame-masked frame-masked ; 1 bit in length
frame-payload-length frame-payload-length ; 7 bits in length
[ frame-masking-key ] [ frame-masking-key ] ; 16 or 64 bits in length
frame-payload-data frame-payload-data ; n * 8 bits in length,
; where n >= 0
frame-fin = %x0 ; more frames of this message follow frame-fin = %x0 ; more frames of this message follow
/ %x1 ; final frame of this message / %x1 ; final frame of this message
; 1 bit in length
frame-rsv1 = %x0 / %x1 frame-rsv1 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit in length, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-rsv2 = %x0 / %x1 frame-rsv2 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit in length, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-rsv3 = %x0 / %x1 frame-rsv3 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit in length, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-opcode = frame-opcode-non-control / frame-opcode = frame-opcode-non-control /
frame-opcode-control frame-opcode-control
frame-opcode-non-control= %x1 ; text frame frame-opcode-non-control= %x1 ; text frame
/ %x2 ; binary frame / %x2 ; binary frame
/ %x3-7 / %x3-7
; reserved for further non-control frames ; reserved for further non-control frames
frame-opcode-control = %x8 ; connection close frame-opcode-control = %x8 ; connection close
/ %x9 ; ping / %x9 ; ping
/ %xA ; pong / %xA ; pong
/ %xB-F ; reserved for further control frames / %xB-F ; reserved for further control frames
; 4 bits in length
frame-masked = %x0 frame-masked = %x0
; frame is not masked, no frame-masking-key ; frame is not masked, no frame-masking-key
/ %x1 / %x1
; frame is masked, frame-masking-key present ; frame is masked, frame-masking-key present
; 1 bit in length
frame-payload-length = %x00-7D frame-payload-length = %x00-7D
/ %x7E frame-payload-length-16 / %x7E frame-payload-length-16
/ %x7F frame-payload-length-63 / %x7F frame-payload-length-63
; 7 bits in length
frame-payload-length-16 = %x0000-FFFF frame-payload-length-16 = %x0000-FFFF ; 16 bits in length
frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
; 64 bits in length
frame-masking-key = 4( %0x00-FF ) frame-masking-key = 4( %0x00-FF )
; present only if frame-masked is 1 ; present only if frame-masked is 1
; 32 bits in length
frame-payload-data = (frame-masked-extension-data frame-payload-data = (frame-masked-extension-data
frame-masked-application-data) frame-masked-application-data)
; frame-masked 1 ; frame-masked 1
/ (frame-unmasked-extension-data / (frame-unmasked-extension-data
frame-unmasked-application-data) frame-unmasked-application-data)
; frame-masked 0 ; frame-masked 0
frame-masked-extension-data = *( %x00-FF ) frame-masked-extension-data = *( %x00-FF )
; reserved for future extensibility ; reserved for future extensibility
; n*8 bits in length , where n >= 0
frame-masked-application-data = *( %x00-FF ) frame-masked-application-data = *( %x00-FF )
; n*8 bits in length, where n >= 0
frame-unmasked-extension-data = *( %x00-FF ) frame-unmasked-extension-data = *( %x00-FF )
; reserved for future extensibility ; reserved for future extensibility
; n*8 bits in length, where n >= 0
frame-unmasked-application-data = *( %x00-FF ) frame-unmasked-application-data = *( %x00-FF )
; n*8 bits in length, where n >= 0
5.3. Client-to-Server Masking 5.3. Client-to-Server Masking
A masked frame MUST have the field frame-masked set to 1, as defined A masked frame MUST have the field frame-masked set to 1, as defined
in Section 5.2. in Section 5.2.
The masking key is contained completely within the frame, as defined The masking key is contained completely within the frame, as defined
in Section 5.2 as frame-masking-key. It is used to mask the payload in Section 5.2 as frame-masking-key. It is used to mask the payload
data defined in the same section as frame-payload-data, which data defined in the same section as frame-payload-data, which
includes extension and application data. includes extension and application data.
skipping to change at page 52, line 27 skipping to change at page 52, line 27
A client requests extensions by including a "Sec-WebSocket- A client requests extensions by including a "Sec-WebSocket-
Extensions" header field, which follows the normal rules for HTTP Extensions" header field, which follows the normal rules for HTTP
header fields (see [RFC2616] section 4.2) and the value of the header header fields (see [RFC2616] section 4.2) and the value of the header
field is defined by the following ABNF [RFC2616]. Note that this field is defined by the following ABNF [RFC2616]. Note that this
section is using ABNF syntax/rules from [RFC2616], including "implied section is using ABNF syntax/rules from [RFC2616], including "implied
*LWS rule". If a value is received by either the client or the *LWS rule". If a value is received by either the client or the
server during negotiation that does not conform to the ABNF below, server during negotiation that does not conform to the ABNF below,
the recipient of such malformed data MUST immediately _Fail the the recipient of such malformed data MUST immediately _Fail the
WebSocket Connection_. WebSocket Connection_.
Sec-WebSocket-Extensions = extension-list Sec-WebSocket-Extensions = extension-list
extension-list = 1#extension extension-list = 1#extension
extension = extension-token *( ";" extension-param ) extension = extension-token *( ";" extension-param )
extension-token = registered-token extension-token = registered-token
registered-token = token registered-token = token
extension-param = token [ "=" (token | quoted-string) ] extension-param = token [ "=" (token | quoted-string) ]
;When using the quoted-string syntax variant, the value ;When using the quoted-string syntax variant, the value
;after quoted-string unescaping MUST conform to the 'token' ABNF. ;after quoted-string unescaping MUST conform to the
;'token' ABNF.
Note that like other HTTP header fields, this header field MAY be Note that like other HTTP header fields, this header field MAY be
split or combined across multiple lines. Ergo, the following are split or combined across multiple lines. Ergo, the following are
equivalent: equivalent:
Sec-WebSocket-Extensions: foo Sec-WebSocket-Extensions: foo
Sec-WebSocket-Extensions: bar; baz=2 Sec-WebSocket-Extensions: bar; baz=2
is exactly equivalent to is exactly equivalent to
skipping to change at page 68, line 33 skipping to change at page 68, line 33
| 8 + draft-ietf-hybi-thewebsocketprotocol-08 | | 8 + draft-ietf-hybi-thewebsocketprotocol-08 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 9 + Reserved | | 9 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 10 + Reserved | | 10 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 11 + Reserved | | 11 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 12 + Reserved | | 12 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 13 + draft-ietf-hybi-thewebsocketprotocol-13 | | 13 + RFCXXXX (RFC Editor: please update) |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
11.7. WebSocket Close Code Number Registry 11.7. WebSocket Close Code Number Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Connection Close Code Numbers in accordance with the WebSocket Connection Close Code Numbers in accordance with the
principles set out in RFC 5226 [RFC5226]. principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
skipping to change at page 75, line 21 skipping to change at page 75, line 21
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-websec-origin] [I-D.ietf-websec-origin]
Barth, A., "The Web Origin Concept", Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-04 (work in progress), draft-ietf-websec-origin-05 (work in progress),
August 2011. September 2011.
14.2. Informative References 14.2. Informative References
[WSAPI] Hickson, I., "The Web Sockets API", August 2010, [WSAPI] Hickson, I., "The Web Sockets API", August 2010,
<http://dev.w3.org/html5/websockets/>. <http://dev.w3.org/html5/websockets/>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
 End of changes. 26 change blocks. 
39 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/