< draft-ietf-hybi-thewebsocketprotocol-15.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 20, 2012 Isode Ltd Expires: April 2, 2012 Isode Ltd
September 17, 2011 September 30, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-15 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 20, 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 17, line 15 skipping to change at page 17, line 15
4. Opening Handshake 4. Opening Handshake
4.1. Client Requirements 4.1. Client Requirements
To _Establish a WebSocket Connection_, a client opens a connection To _Establish a WebSocket Connection_, a client opens a connection
and sends a handshake as defined in this section. A connection is and sends a handshake as defined in this section. A connection is
defined to initially be in a CONNECTING state. A client will need to defined to initially be in a CONNECTING state. A client will need to
supply a /host/, /port/, /resource name/, and a /secure/ flag, which supply a /host/, /port/, /resource name/, and a /secure/ flag, which
are the components of a WebSocket URI as discussed in Section 3, are the components of a WebSocket URI as discussed in Section 3,
along with a list of /protocols/ and /extensions/ to be used. along with a list of /protocols/ and /extensions/ to be used.
Additionally, if the client is a web browser, an /origin/ MUST be Additionally, if the client is a web browser, it supplies /origin/.
supplied.
Clients running in controlled environments, e.g. browsers on mobile Clients running in controlled environments, e.g. browsers on mobile
handsets tied to specific carriers, MAY offload the management of the handsets tied to specific carriers, MAY offload the management of the
connection to another agent on the network. In such a situation, the connection to another agent on the network. In such a situation, the
client for the purposes of this specification is considered to client for the purposes of this specification is considered to
include both the handset software and any such agents. include both the handset software and any such agents.
When the client is to _Establish a WebSocket Connection_ given a set When the client is to _Establish a WebSocket Connection_ given a set
of (/host/, /port/, /resource name/, and /secure/ flag), along with a of (/host/, /port/, /resource name/, and /secure/ flag), along with a
list of /protocols/ and /extensions/ to be used, and an /origin/ in list of /protocols/ and /extensions/ to be used, and an /origin/ in
skipping to change at page 18, line 11 skipping to change at page 18, line 10
If the client cannot determine the IP address of the remote host If the client cannot determine the IP address of the remote host
(for example because all communication is being done through a (for example because all communication is being done through a
proxy server that performs DNS queries itself), then the client proxy server that performs DNS queries itself), then the client
MUST assume for the purposes of this step that each host name MUST assume for the purposes of this step that each host name
refers to a distinct remote host, and instead the client SHOULD refers to a distinct remote host, and instead the client SHOULD
limit the total number of simultaneous pending connections to a limit the total number of simultaneous pending connections to a
reasonably low number (e.g., the client might allow simultaneous reasonably low number (e.g., the client might allow simultaneous
pending connections to a.example.com and b.example.com, but if pending connections to a.example.com and b.example.com, but if
thirty simultaneous connections to a single host are requested, thirty simultaneous connections to a single host are requested,
that may not be allowed). In a Web browser context, the client that may not be allowed). For example in a Web browser context,
SHOULD consider the number of tabs the user has open in setting a the client needs to consider the number of tabs the user has open
limit to the number of simultaneous pending connections. in setting a limit to the number of simultaneous pending
connections.
NOTE: This makes it harder for a script to perform a denial of NOTE: This makes it harder for a script to perform a denial of
service attack by just opening a large number of WebSocket service attack by just opening a large number of WebSocket
connections to a remote host. A server can further reduce the connections to a remote host. A server can further reduce the
load on itself when attacked by pausing before closing the load on itself when attacked by pausing before closing the
connection, as that will reduce the rate at which the client connection, as that will reduce the rate at which the client
reconnects. reconnects.
NOTE: There is no limit to the number of established WebSocket NOTE: There is no limit to the number of established WebSocket
connections a client can have with a single remote host. Servers connections a client can have with a single remote host. Servers
skipping to change at page 26, line 43 skipping to change at page 26, line 43
of this concatenated value to obtain a 20-byte value, and of this concatenated value to obtain a 20-byte value, and
base64-encoding (see Section 4 of [RFC4648]) this 20-byte base64-encoding (see Section 4 of [RFC4648]) this 20-byte
hash. hash.
The ABNF [RFC2616] of this header field is defined as The ABNF [RFC2616] of this header field is defined as
follows: follows:
Sec-WebSocket-Accept = base64-value-non-empty Sec-WebSocket-Accept = base64-value-non-empty
base64-value-non-empty = (1*base64-data [ base64-padding ]) | base64-value-non-empty = (1*base64-data [ base64-padding ]) |
base64-padding base64-padding
base64-value = *base64-data [ base64-padding ]
base64-data = 4base64-character base64-data = 4base64-character
base64-padding = (2base64-character "==") | base64-padding = (2base64-character "==") |
(3base64-character "=") (3base64-character "=")
base64-character = ALPHA | DIGIT | "+" | "/" base64-character = ALPHA | DIGIT | "+" | "/"
NOTE: As an example, if the value of the "Sec-WebSocket-Key" NOTE: As an example, if the value of the "Sec-WebSocket-Key"
header field in the client's handshake were header field in the client's handshake were
"dGhlIHNhbXBsZSBub25jZQ==", the server would append the "dGhlIHNhbXBsZSBub25jZQ==", the server would append the
string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the
string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
skipping to change at page 30, line 13 skipping to change at page 30, line 13
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
5. Data Framing 5. Data Framing
5.1. Overview 5.1. Overview
In the WebSocket protocol, data is transmitted using a sequence of In the WebSocket protocol, data is transmitted using a sequence of
frames. To avoid confusing network intermediaries (such as frames. To avoid confusing network intermediaries (such as
intercepting proxies) and for security reasons that are further intercepting proxies) and for security reasons that are further
discussed in Section 10.3, a client MUST mask all frames that it discussed in Section 10.3, a client MUST mask all frames that it
sends to the server (see Section 5.3 for further details). The sends to the server (see Section 5.3 for further details). (Note
server MUST close the connection upon receiving a frame that is not that masking is done whether or not the WebSocket protocol is running
masked. In this case, a server MAY send a close frame with a status over TLS.) The server MUST close the connection upon receiving a
code of 1002 (protocol error) as defined in Section 7.4.1. A server frame that is not masked. In this case, a server MAY send a close
MUST NOT mask any frames that it sends to the client. A client MUST frame with a status code of 1002 (protocol error) as defined in
close a connection if it detects a masked frame. In this case, it Section 7.4.1. A server MUST NOT mask any frames that it sends to
MAY use the status code 1002 (protocol error) as defined in the client. A client MUST close a connection if it detects a masked
Section 7.4.1. (These rules might be relaxed in a future frame. In this case, it MAY use the status code 1002 (protocol
specification.) error) as defined in Section 7.4.1. (These rules might be relaxed in
a future specification.)
The base framing protocol defines a frame type with an opcode, a The base framing protocol defines a frame type with an opcode, a
payload length, and designated locations for extension and payload length, and designated locations for extension and
application data, which together define the _payload_ data. Certain application data, which together define the _payload_ data. Certain
bits and opcodes are reserved for future expansion of the protocol. bits and opcodes are reserved for future expansion of the protocol.
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. A high level overview of [RFC5234] given in detail in this section. (Note that unlike in
the framing is given in the following figure. In a case of conflict other sections of this document the ABNF in this section is operating
between the figure below and the ABNF specified later in this on groups of bits. The length of each group of bits is indicated in
section, the ABNF version should be considered to be more a comment. When encoded on the wire the most significant bit is the
leftmost in the ABNF). A high level overview of the framing is given
in the following figure. In a case of conflict between the figure
below and the ABNF specified later in this section, the figure is
authoritative. 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.
The masking key is a 32-bit value chosen at random by the client. The masking key is a 32-bit value chosen at random by the client.
The masking key MUST be derived from a strong source of entropy, and When preparing a masked frame, the client MUST pick a fresh masking
the masking key for a given frame MUST NOT make it simple for a key from the set of allowed 32-bit values. The masking key needs to
server to predict the masking key for a subsequent frame. RFC 4086 be unpredictable, thus the masking key MUST be derived from a strong
[RFC4086] discusses what entails a suitable source of entropy for source of entropy, and the masking key for a given frame MUST NOT
security-sensitive applications. make it simple for a server/proxy to predict the masking key for a
subsequent frame. The unpredictability of the masking key is
essential to prevent the author of malicious applications from
selecting the bytes that appear on the wire. RFC 4086 [RFC4086]
discusses what entails a suitable source of entropy for security-
sensitive applications.
The masking does not affect the length of the payload data. To The masking does not affect the length of the payload data. To
convert masked data into unmasked data, or vice versa, the following convert masked data into unmasked data, or vice versa, the following
algorithm is applied. The same algorithm applies regardless of the algorithm is applied. The same algorithm applies regardless of the
direction of the translation - e.g. the same steps are applied to direction of the translation - e.g. the same steps are applied to
mask the data as to unmask the data. mask the data as to unmask the data.
Octet i of the transformed data ("transformed-octet-i") is the XOR of Octet i of the transformed data ("transformed-octet-i") is the XOR of
octet i of the original data ("original-octet-i") with octet at index octet i of the original data ("original-octet-i") with octet at index
i modulo 4 of the masking key ("masking-key-octet-j"): i modulo 4 of the masking key ("masking-key-octet-j"):
j = i MOD 4 j = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j transformed-octet-i = original-octet-i XOR masking-key-octet-j
When preparing a masked frame, the client MUST pick a fresh masking
key from the set of allowed 32-bit values. The masking key must be
unpredictable. The unpredictability of the masking key is essential
to prevent the author of malicious applications from selecting the
bytes that appear on the wire.
The payload length, indicated in the framing as frame-payload-length, The payload length, indicated in the framing as frame-payload-length,
does NOT include the length of the masking key. It is the length of does NOT include the length of the masking key. It is the length of
the payload data, e.g. the number of bytes following the masking key. the payload data, e.g. the number of bytes following the masking key.
5.4. Fragmentation 5.4. Fragmentation
The primary purpose of fragmentation is to allow sending a message The primary purpose of fragmentation is to allow sending a message
that is of unknown size when the message is started without having to that is of unknown size when the message is started without having to
buffer that message. If messages couldn't be fragmented, then an buffer that message. If messages couldn't be fragmented, then an
endpoint would have to buffer the entire message so its length could endpoint would have to buffer the entire message so its length could
skipping to change at page 37, line 21 skipping to change at page 37, line 41
o As control frames cannot be fragmented, an intermediary MUST NOT o As control frames cannot be fragmented, an intermediary MUST NOT
attempt to change the fragmentation of a control frame. attempt to change the fragmentation of a control frame.
o An intermediary MUST NOT change the fragmentation of a message if o An intermediary MUST NOT change the fragmentation of a message if
any reserved bit values are used and the meaning of these values any reserved bit values are used and the meaning of these values
is not known to the intermediary. is not known to the intermediary.
o An intermediary MUST NOT change the fragmentation of any message o An intermediary MUST NOT change the fragmentation of any message
in the context of a connection where extensions have been in the context of a connection where extensions have been
negotiated and the intermediary is not aware of the semantics of negotiated and the intermediary is not aware of the semantics of
the negotiated extensions. the negotiated extensions. Similarly, an intermediary that didn't
see the WebSocket handshake (and wasn't notified about its
content) that resulted in a WebSocket connection MUST NOT change
the fragmentation of any message of such connection.
o As a consequence of these rules, all fragments of a message are of o As a consequence of these rules, all fragments of a message are of
the same type, as set by the first fragment's opcode. Since the same type, as set by the first fragment's opcode. Since
Control frames cannot be fragmented, the type for all fragments in Control frames cannot be fragmented, the type for all fragments in
a message MUST be either text or binary, or one of the reserved a message MUST be either text or binary, or one of the reserved
opcodes. opcodes.
_Note: if control frames could not be interjected, the latency of a _Note: if control frames could not be interjected, the latency of a
ping, for example, would be very long if behind a large message. ping, for example, would be very long if behind a large message.
Hence, the requirement of handling control frames in the middle of a Hence, the requirement of handling control frames in the middle of a
skipping to change at page 38, line 32 skipping to change at page 39, line 7
users. users.
Close frames sent from client to server must be masked as per Close frames sent from client to server must be masked as per
Section 5.3. Section 5.3.
The application MUST NOT send any more data frames after sending a The application MUST NOT send any more data frames after sending a
close frame. close frame.
If an endpoint receives a Close frame and that endpoint did not If an endpoint receives a Close frame and that endpoint did not
previously send a Close frame, the endpoint MUST send a Close frame previously send a Close frame, the endpoint MUST send a Close frame
in response. It SHOULD do so as soon as is practical. An endpoint in response. (When sending a Close frame in response the endpoint
MAY delay sending a close frame until its current message is sent typically echos the status code it received.) It SHOULD do so as
(for instance, if the majority of a fragmented message is already soon as practical. An endpoint MAY delay sending a close frame until
sent, an endpoint MAY send the remaining fragments before sending a its current message is sent (for instance, if the majority of a
Close frame). However, there is no guarantee that the endpoint which fragmented message is already sent, an endpoint MAY send the
has already sent a Close frame will continue to process data. remaining fragments before sending a Close frame). However, there is
no guarantee that the endpoint which has already sent a Close frame
will continue to process data.
After both sending and receiving a close message, an endpoint After both sending and receiving a close message, an endpoint
considers the WebSocket connection closed, and MUST close the considers the WebSocket connection closed, and MUST close the
underlying TCP connection. The server MUST close the underlying TCP underlying TCP connection. The server MUST close the underlying TCP
connection immediately; the client SHOULD wait for the server to connection immediately; the client SHOULD wait for the server to
close the connection but MAY close the connection at any time after close the connection but MAY close the connection at any time after
sending and receiving a close message, e.g. if it has not received a sending and receiving a close message, e.g. if it has not received a
TCP close from the server in a reasonable time period. TCP close from the server in a reasonable time period.
If a client and server both send a Close message at the same time, If a client and server both send a Close message at the same time,
skipping to change at page 52, line 34 skipping to change at page 52, line 34
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 54, line 38 skipping to change at page 54, line 38
EXAMPLE: For example, if the server uses input as part of SQL EXAMPLE: For example, if the server uses input as part of SQL
queries, all input text should be escaped before being passed to the queries, all input text should be escaped before being passed to the
SQL server, lest the server be susceptible to SQL injection. SQL server, lest the server be susceptible to SQL injection.
10.2. Origin Considerations 10.2. Origin Considerations
Servers that are not intended to process input from any Web page but Servers that are not intended to process input from any Web page but
only for certain sites SHOULD verify the "Origin" field is an origin only for certain sites SHOULD verify the "Origin" field is an origin
they expect. If the origin indicated is unacceptable to the server, they expect. If the origin indicated is unacceptable to the server,
then it SHOULD respond to the WebSocket handshake with a reply then it SHOULD respond to the WebSocket handshake with a reply
containing HTTP 403 Unauthorized status code. containing HTTP 403 Forbidden status code.
The "Origin" header field protects from the attack cases when the The "Origin" header field protects from the attack cases when the
untrusted party is typically the author of a JavaScript application untrusted party is typically the author of a JavaScript application
that is executing in the context of the trusted client. The client that is executing in the context of the trusted client. The client
itself can contact the server and via the mechanism of the "Origin" itself can contact the server and via the mechanism of the "Origin"
header field, determine whether to extend those communication header field, determine whether to extend those communication
privileges to the JavaScript application. The intent is not to privileges to the JavaScript application. The intent is not to
prevent non-browsers from establishing connections, but rather to prevent non-browsers from establishing connections, but rather to
ensure that trusted browsers under the control of potentially ensure that trusted browsers under the control of potentially
malicious JavaScript cannot fake a WebSocket handshake. malicious JavaScript cannot fake a WebSocket handshake.
skipping to change at page 56, line 33 skipping to change at page 56, line 33
to forge a request. As such, it was not deemed necessary to mask to forge a request. As such, it was not deemed necessary to mask
data in both directions (the data from the server to the client is data in both directions (the data from the server to the client is
not masked). not masked).
Despite the protection provided by masking, non-compliant HTTP Despite the protection provided by masking, non-compliant HTTP
proxies will still be vulnerable to poisoning attacks of this type by proxies will still be vulnerable to poisoning attacks of this type by
clients and servers that do not apply masking. clients and servers that do not apply masking.
10.4. Implementation-Specific Limits 10.4. Implementation-Specific Limits
Implementations MUST impose implementation-specific limits on Implementations which have implementation- and/or platform-specific
otherwise unconstrained inputs, e.g. to prevent denial of service limitations regarding the frame size or total message size after
attacks, to guard against running out of memory, or to work around reassembly from multiple frames MUST protect themselves against
platform-specific limitations. In particular, a malicious endpoint exceeding those limits. (For example, a malicious endpoint can try
can try to exhaust its peer's memory by sending either a single big to exhaust its peer's memory or mount a denial of service attack by
frame (e.g. of size 2**60), or by sending a long stream of small sending either a single big frame (e.g. of size 2**60), or by sending
frames which are a part of a fragmented message. In order to protect a long stream of small frames which are a part of a fragmented
from this implementations SHOULD impose limit on frame sizes and the message.) Such an implementation SHOULD impose limit on frame sizes
total message size after reassembly from multiple frames. and the total message size after reassembly from multiple frames.
10.5. WebSocket client authentication 10.5. WebSocket client authentication
This protocol doesn't prescribe any particular way that servers can This protocol doesn't prescribe any particular way that servers can
authenticate clients during the WebSocket handshake. The WebSocket authenticate clients during the WebSocket handshake. The WebSocket
server can use any client authentication mechanism available to a server can use any client authentication mechanism available to a
generic HTTP server, such as Cookies, HTTP Authentication, or TLS generic HTTP server, such as Cookies, HTTP Authentication, or TLS
authentication. authentication.
10.6. Connection confidentiality and integrity 10.6. Connection confidentiality and integrity
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 73, line 40 skipping to change at page 73, line 40
Thank you to the following people who participated in discussions on Thank you to the following people who participated in discussions on
the HYBI WG mailing list and contributed ideas and/or provided the HYBI WG mailing list and contributed ideas and/or provided
detailed reviews (the list is likely to be incomplete): Greg Wilkins, detailed reviews (the list is likely to be incomplete): Greg Wilkins,
John Tamplin, Willy Tarreau, Maciej Stachowiak, Jamie Lokier, Scott John Tamplin, Willy Tarreau, Maciej Stachowiak, Jamie Lokier, Scott
Ferguson, Bjoern Hoehrmann, Julian Reschke, Dave Cridland, Andy Ferguson, Bjoern Hoehrmann, Julian Reschke, Dave Cridland, Andy
Green, Eric Rescorla, Inaki Baz Castillo, Martin Thomson, Roberto Green, Eric Rescorla, Inaki Baz Castillo, Martin Thomson, Roberto
Peon, Patrick McManus, Zhong Yu, Bruce Atherton, Takeshi Yoshino, Peon, Patrick McManus, Zhong Yu, Bruce Atherton, Takeshi Yoshino,
Martin J. Duerst, James Graham, Simon Pieters, Roy T. Fielding, Martin J. Duerst, James Graham, Simon Pieters, Roy T. Fielding,
Mykyta Yevstifeyev, Len Holgate, Paul Colomiets, Piotr Kulaga, Brian Mykyta Yevstifeyev, Len Holgate, Paul Colomiets, Piotr Kulaga, Brian
Raymor, Jan Koehler, Joonas Lehtolahti, Sylvain Hellegouarch, Stephen Raymor, Jan Koehler, Joonas Lehtolahti, Sylvain Hellegouarch, Stephen
Farrell, Sean Turner, Pete Resnick, Peter Thorson, Joe Mason. Note Farrell, Sean Turner, Pete Resnick, Peter Thorson, Joe Mason, John
that people listed above didn't necessarily endorse the end result of Fallows, Alexander Philippou. Note that people listed above didn't
this work. necessarily endorse the end result of this work.
14. References 14. References
14.1. Normative References 14.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
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.
skipping to change at page 75, line 48 skipping to change at page 75, line 48
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long "Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202, Polling and Streaming in Bidirectional HTTP", RFC 6202,
April 2011. April 2011.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270, November 2005. Hashes in Internet Protocols", RFC 4270, November 2005.
[W3C.REC-wsc-ui-20100812] [W3C.REC-wsc-ui-20100812]
Saldhana, A. and T. Roessler, "Web Security Context: User Roessler, T. and A. Saldhana, "Web Security Context: User
Interface Guidelines", World Wide Web Consortium Interface Guidelines", World Wide Web Consortium
Recommendation REC-wsc-ui-20100812, August 2010, Recommendation REC-wsc-ui-20100812, August 2010,
<http://www.w3.org/TR/2010/REC-wsc-ui-20100812>. <http://www.w3.org/TR/2010/REC-wsc-ui-20100812>.
[TALKING] Huang, L-S., Chen, E., Barth, A., and E. Rescorla, [TALKING] Huang, L-S., Chen, E., Barth, A., and E. Rescorla,
"Talking to Yourself for Fun and Profit", 2010, <http:// "Talking to Yourself for Fun and Profit", 2010, <http://
www.adambarth.com/papers/2011/ www.adambarth.com/papers/2011/
huang-chen-barth-rescorla-jackson.pdf>. huang-chen-barth-rescorla-jackson.pdf>.
[XMLHttpRequest] [XMLHttpRequest]
 End of changes. 38 change blocks. 
78 lines changed or deleted 110 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/
X-Generator: pyht 0.35