draft-ietf-hybi-thewebsocketprotocol-13.txt   draft-ietf-hybi-thewebsocketprotocol-14.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 3, 2012 Isode Ltd Expires: March 11, 2012 Isode Ltd
August 31, 2011 September 8, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-13 draft-ietf-hybi-thewebsocketprotocol-14
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 3, 2012. This Internet-Draft will expire on March 11, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 7 1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 7
1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 9 1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 10
1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 10 1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 10
1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 11 1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 11
1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 12 1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 12
1.8. Establishing a Connection . . . . . . . . . . . . . . . . 12 1.8. Establishing a Connection . . . . . . . . . . . . . . . . 12
1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 12 1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 12
2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 14 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 14
3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 16 3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 16
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
5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4. Supporting multiple versions of WebSocket protocol . . . . 28
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 29 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 33 5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 30
5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 34 5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 34
5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 36 5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 35
5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 36 5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 37
5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 38 5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 39
5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 39 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 40
6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 40 5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 40 6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 42
6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 40 6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 42
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 42 6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 42 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 44
7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 42 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 42 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 44
7.1.3. The WebSocket Closing Handshake is Started . . . . . . 42 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 44
7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 43 7.1.3. The WebSocket Closing Handshake is Started . . . . . . 44
7.1.5. The WebSocket Connection Close Code . . . . . . . . . 43 7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 45
7.1.6. The WebSocket Connection Close Reason . . . . . . . . 43 7.1.5. The WebSocket Connection Close Code . . . . . . . . . 45
7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 44 7.1.6. The WebSocket Connection Close Reason . . . . . . . . 45
7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 44 7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 46
7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 44 7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 46
7.2.2. Server-Initiated Closure . . . . . . . . . . . . . . . 45 7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 46
7.2.3. Recovering From Abnormal Closure . . . . . . . . . . . 45 7.2.2. Server-Initiated Closure . . . . . . . . . . . . . . . 47
7.3. Normal Closure of Connections . . . . . . . . . . . . . . 45 7.2.3. Recovering From Abnormal Closure . . . . . . . . . . . 47
7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 45 7.3. Normal Closure of Connections . . . . . . . . . . . . . . 47
7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 46 7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 47
7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 47 7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 48
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 49 7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 49
8.1. Handling Errors in UTF-8 Encoded Data . . . . . . . . . . 49 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 51
9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.1. Handling Errors in UTF-8 Encoded Data . . . . . . . . . . 51
9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 50 9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 51 9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 52
10. Security Considerations . . . . . . . . . . . . . . . . . . . 52 9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 53
10.1. Non-Browser Clients . . . . . . . . . . . . . . . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 54
10.2. Origin Considerations . . . . . . . . . . . . . . . . . . 52 10.1. Non-Browser Clients . . . . . . . . . . . . . . . . . . . 54
10.3. Attacks On Infrastructure (Masking) . . . . . . . . . . . 53 10.2. Origin Considerations . . . . . . . . . . . . . . . . . . 54
10.4. Implementation-Specific Limits . . . . . . . . . . . . . . 54 10.3. Attacks On Infrastructure (Masking) . . . . . . . . . . . 55
10.5. WebSocket client authentication . . . . . . . . . . . . . 54 10.4. Implementation-Specific Limits . . . . . . . . . . . . . . 56
10.6. Connection confidentiality and integrity . . . . . . . . . 55 10.5. WebSocket client authentication . . . . . . . . . . . . . 56
10.7. Handling of invalid data . . . . . . . . . . . . . . . . . 55 10.6. Connection confidentiality and integrity . . . . . . . . . 57
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 10.7. Handling of invalid data . . . . . . . . . . . . . . . . . 57
11.1. Registration of new URI Schemes . . . . . . . . . . . . . 56 10.8. Use of SHA-1 by the WebSocket protocol . . . . . . . . . . 57
11.1.1. Registration of "ws" Scheme . . . . . . . . . . . . . 56 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
11.1.2. Registration of "wss" Scheme . . . . . . . . . . . . . 57 11.1. Registration of new URI Schemes . . . . . . . . . . . . . 59
11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 58 11.1.1. Registration of "ws" Scheme . . . . . . . . . . . . . 59
11.3. Registration of new HTTP Header Fields . . . . . . . . . . 58 11.1.2. Registration of "wss" Scheme . . . . . . . . . . . . . 60
11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 58 11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 61
11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 59 11.3. Registration of new HTTP Header Fields . . . . . . . . . . 61
11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 60 11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 61
11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 60 11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 62
11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 61 11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 63
11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 62 11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 64
11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 62 11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 64
11.6. WebSocket Version Number Registry . . . . . . . . . . . . 63 11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 65
11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 64 11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 66
11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 66 11.6. WebSocket Version Number Registry . . . . . . . . . . . . 66
11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 67 11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 68
12. Using the WebSocket protocol from Other Specifications . . . . 68 11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 70
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 71
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 12. Using the WebSocket protocol from Other Specifications . . . . 72
14.1. Normative References . . . . . . . . . . . . . . . . . . . 70 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 73
14.2. Informative References . . . . . . . . . . . . . . . . . . 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 14.1. Normative References . . . . . . . . . . . . . . . . . . . 74
14.2. Informative References . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
1.1. Background 1.1. Background
_This section is non-normative._ _This section is non-normative._
Historically, creating Web applications that need bidirectional Historically, creating Web applications that need bidirectional
communication between a client and a server (e.g., instant messaging communication between a client and a server (e.g., instant messaging
and gaming applications) has required an abuse of HTTP to poll the and gaming applications) has required an abuse of HTTP to poll the
skipping to change at page 5, line 40 skipping to change at page 5, line 40
traffic in both directions. This is what the WebSocket protocol traffic in both directions. This is what the WebSocket protocol
provides. Combined with the WebSocket API, it provides an provides. Combined with the WebSocket API, it provides an
alternative to HTTP polling for two-way communication from a Web page alternative to HTTP polling for two-way communication from a Web page
to a remote server. [WSAPI] to a remote server. [WSAPI]
The same technique can be used for a variety of Web applications: The same technique can be used for a variety of Web applications:
games, stock tickers, multiuser applications with simultaneous games, stock tickers, multiuser applications with simultaneous
editing, user interfaces exposing server-side services in real time, editing, user interfaces exposing server-side services in real time,
etc. etc.
The WebSocket protocol is designed to supersede existing
bidirectional communication technologies which use HTTP as a
transport layer to benefit from existing infrastructure (proxies,
filtering, authentication). Such technologies were implemented as
trade-offs between efficiency and reliability because HTTP was not
initially meant to be used for bidirectional communication (see
[RFC6202] for further discussion). The WebSocket protocol attempts
to address the goals of existing bidirectional HTTP technologies in
the context of the existing HTTP infrastructure; as such, it is
designed to work over HTTP ports 80 and 443 as well as to support
HTTP proxies and intermediaries, even if this implies some complexity
specific to the current environment. However, the design does not
limit WebSocket to HTTP, and future implementations could use a
simpler handshake over a dedicated port without revinventing the
entire protocol. This last point is important because the traffic
patterns of interactive messaging do not closely match standard HTTP
traffic and can induce unusual loads on some components.
1.2. Protocol Overview 1.2. Protocol Overview
_This section is non-normative._ _This section is non-normative._
The protocol has two parts: a handshake, and then the data transfer. The protocol has two parts: a handshake, and then the data transfer.
The handshake from the client looks as follows: The handshake from the client looks as follows:
GET /chat HTTP/1.1 GET /chat HTTP/1.1
Host: server.example.com Host: server.example.com
skipping to change at page 14, line 26 skipping to change at page 14, line 26
"strip any leading space characters" or "return false and abort these "strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word steps") are to be interpreted with the meaning of the key word
("must", "should", "may", etc) used in introducing the algorithm. ("must", "should", "may", etc) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps MAY Conformance requirements phrased as algorithms or specific steps MAY
be implemented in any manner, so long as the end result is be implemented in any manner, so long as the end result is
equivalent. (In particular, the algorithms defined in this equivalent. (In particular, the algorithms defined in this
specification are intended to be easy to follow, and not intended to specification are intended to be easy to follow, and not intended to
be performant.) be performant.)
The conformance classes defined by this specification are clients and
servers.
2.1. Terminology 2.1. Terminology
_ASCII_ shall mean the character-encoding scheme defined in _ASCII_ shall mean the character-encoding scheme defined in
[ANSI.X3-4.1986]. [ANSI.X3-4.1986].
This document makes reference to UTF-8 values and uses UTF-8 This document makes reference to UTF-8 values and uses UTF-8
notational formats as defined in STD 63 [RFC3629]. notational formats as defined in STD 63 [RFC3629].
Key Terms such as named algorithms or definitions are indicated like Key Terms such as named algorithms or definitions are indicated like
_this_. _this_.
skipping to change at page 17, line 21 skipping to change at page 17, line 21
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, an /origin/ MUST be
supplied. 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 conformance is considered to include both client for the purposes of this specification is considered to
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
the case of web browsers, it MUST open a connection, send an opening the case of web browsers, it MUST open a connection, send an opening
handshake, and read the server's handshake in response. The exact handshake, and read the server's handshake in response. The exact
requirements of how the connection should be opened, what should be requirements of how the connection should be opened, what should be
sent in the opening handshake, and how the server's response should sent in the opening handshake, and how the server's response should
be interpreted, are as follows in this section. In the following be interpreted, are as follows in this section. In the following
text, we will use terms from Section 3 such as "/host/" and "/secure/ text, we will use terms from Section 3 such as "/host/" and "/secure/
skipping to change at page 20, line 41 skipping to change at page 20, line 41
8. The request MUST include a header field with the name "Origin" 8. The request MUST include a header field with the name "Origin"
[I-D.ietf-websec-origin] if the request is coming from a browser [I-D.ietf-websec-origin] if the request is coming from a browser
client. If the connection is from a non-browser client, the client. If the connection is from a non-browser client, the
request MAY include this header field if the semantics of that request MAY include this header field if the semantics of that
client match the use-case described here for browser clients. client match the use-case described here for browser clients.
The value of this header field is the ASCII serialization of The value of this header field is the ASCII serialization of
origin of the context in which the code establishing the origin of the context in which the code establishing the
connection is running. See [I-D.ietf-websec-origin] for the connection is running. See [I-D.ietf-websec-origin] for the
details of how this header field value is constructed. details of how this header field value is constructed.
As an example, if code is running on www.example.com attempting As an example, if code downloaded from www.example.com attempts
to establish a connection to ww2.example.com, the value of the to establish a connection to ww2.example.com, the value of the
header field would be "http://www.example.com". header field would be "http://www.example.com".
9. The request MUST include a header field with the name "Sec- 9. The request MUST include a header field with the name "Sec-
WebSocket-Version". The value of this header field MUST be 13. WebSocket-Version". The value of this header field MUST be 13.
_Note: Although drafts -09, -10, -11 and -12 were published, as _Note: Although drafts -09, -10, -11 and -12 were published, as
they were mostly comprised of editorial changes and they were mostly comprised of editorial changes and
clarifications and not changes to the wire protocol, values 9, clarifications and not changes to the wire protocol, values 9,
10, 11 and 12 were not used as valid values for Sec-WebSocket- 10, 11 and 12 were not used as valid values for Sec-WebSocket-
Version. These values were reserved in the IANA registry but Version. These values were reserved in the IANA registry but
skipping to change at page 21, line 24 skipping to change at page 21, line 24
constructs and rules are as given in [RFC2616]. constructs and rules are as given in [RFC2616].
11. The request MAY include a header field with the name "Sec- 11. The request MAY include a header field with the name "Sec-
WebSocket-Extensions". If present, this value indicates the WebSocket-Extensions". If present, this value indicates the
protocol-level extension(s) the client wishes to speak. The protocol-level extension(s) the client wishes to speak. The
interpretation and format of this header field is described in interpretation and format of this header field is described in
Section 9.1. Section 9.1.
12. The request MAY include any other header fields, for example 12. The request MAY include any other header fields, for example
cookies [RFC6265] and/or authentication related header fields cookies [RFC6265] and/or authentication related header fields
such as Authorization header field [RFC2616]. such as Authorization header field [RFC2616], which are
processed according to documents that define them.
Once the client's opening handshake has been sent, the client MUST Once the client's opening handshake has been sent, the client MUST
wait for a response from the server before sending any further data. wait for a response from the server before sending any further data.
The client MUST validate the server's response as follows: The client MUST validate the server's response as follows:
1. If the status code received from the server is not 101, the 1. If the status code received from the server is not 101, the
client handles the response per HTTP [RFC2616] procedures, in client handles the response per HTTP [RFC2616] procedures, in
particular the client might perform authentication if it receives particular the client might perform authentication if it receives
401 status code, the server might redirect the client using a 3xx 401 status code, the server might redirect the client using a 3xx
status code (but clients are not required to follow them), etc. status code (but clients are not required to follow them), etc.
Otherwise, proceed as follows. Otherwise, proceed as follows.
2. If the response lacks an "Upgrade" header field or the "Upgrade" 2. If the response lacks an "Upgrade" header field or the "Upgrade"
header field contains a value that is not an ASCII case- header field contains a value that is not an ASCII case-
insensitive match for the value "websocket", the client MUST insensitive match for the value "websocket", the client MUST
_Fail the WebSocket Connection _. _Fail the WebSocket Connection _.
3. If the response lacks a "Connection" header field or the 3. If the response lacks a "Connection" header field or the
"Connection" header field doesn't contains a token that is an "Connection" header field doesn't contain a token that is an
ASCII case-insensitive match for the value "Upgrade", the client ASCII case-insensitive match for the value "Upgrade", the client
MUST _Fail the WebSocket Connection_. MUST _Fail the WebSocket Connection_.
4. If the response lacks a "Sec-WebSocket-Accept" header field or 4. If the response lacks a "Sec-WebSocket-Accept" header field or
the "Sec-WebSocket-Accept" contains a value other than the the "Sec-WebSocket-Accept" contains a value other than the
base64-encoded SHA-1 of the concatenation of the "Sec-WebSocket- base64-encoded SHA-1 of the concatenation of the "Sec-WebSocket-
Key" (as a string, not base64-decoded) with the string "258EAFA5- Key" (as a string, not base64-decoded) with the string "258EAFA5-
E914-47DA-95CA-C5AB0DC85B11", but ignoring any leading and E914-47DA-95CA-C5AB0DC85B11", but ignoring any leading and
trailing whitespace, the client MUST _Fail the WebSocket trailing whitespace, the client MUST _Fail the WebSocket
Connection_ Connection_
skipping to change at page 22, line 19 skipping to change at page 22, line 20
that was not present in the client' handshake (the server has that was not present in the client' handshake (the server has
indicated an extension not requested by the client), the client indicated an extension not requested by the client), the client
MUST _Fail the WebSocket Connection_. (The parsing of this MUST _Fail the WebSocket Connection_. (The parsing of this
header field to determine which extensions are requested is header field to determine which extensions are requested is
discussed in Section 9.1.) discussed in Section 9.1.)
6. If the response includes a "Sec-WebSocket-Protocol" header field, 6. If the response includes a "Sec-WebSocket-Protocol" header field,
and this header field indicates the use of a subprotocol that was and this header field indicates the use of a subprotocol that was
not present in the client' handshake (the server has indicated a not present in the client' handshake (the server has indicated a
subprotocol not requested by the client), the client MUST _Fail subprotocol not requested by the client), the client MUST _Fail
the WebSocket Connection_. (The parsing of this header field to the WebSocket Connection_.
determine which extensions are requested is discussed in
Section 9.1.)
If the server's response does not conform to the requirements for the If the server's response does not conform to the requirements for the
server's handshake as defined in this section and in Section 4.2.2, server's handshake as defined in this section and in Section 4.2.2,
the client MUST _Fail the WebSocket Connection_. the client MUST _Fail the WebSocket Connection_.
Please note that according to [RFC2616] all header field names in
both HTTP requests and HTTP responses are case-insensitive.
If the server's response is validated as provided for above, it is If the server's response is validated as provided for above, it is
said that _The WebSocket Connection is Established_ and that the said that _The WebSocket Connection is Established_ and that the
WebSocket Connection is in the OPEN state. The _Extensions In Use_ WebSocket Connection is in the OPEN state. The _Extensions In Use_
is defined to be a (possibly empty) string, the value of which is is defined to be a (possibly empty) string, the value of which is
equal to the value of the |Sec-WebSocket-Extensions| header field equal to the value of the |Sec-WebSocket-Extensions| header field
supplied by the server's handshake, or the null value if that header supplied by the server's handshake, or the null value if that header
field was not present in the server's handshake. The _Subprotocol In field was not present in the server's handshake. The _Subprotocol In
Use_ is defined to be the value of the |Sec-WebSocket-Protocol| Use_ is defined to be the value of the |Sec-WebSocket-Protocol|
header field in the server's handshake, or the null value if that header field in the server's handshake, or the null value if that
header field was not present in the server's handshake. header field was not present in the server's handshake.
Additionally, if any header fields in the server's handshake indicate Additionally, if any header fields in the server's handshake indicate
that cookies should be set (as defined by [RFC6265]), these cookies that cookies should be set (as defined by [RFC6265]), these cookies
are referred to as _Cookies Set During the Server's Opening are referred to as _Cookies Set During the Server's Opening
Handshake_. Handshake_.
4.2. Server-side Requirements 4.2. Server-side Requirements
_This section only applies to servers._
Servers MAY offload the management of the connection to other agents Servers MAY offload the management of the connection to other agents
on the network, for example load balancers and reverse proxies. In on the network, for example load balancers and reverse proxies. In
such a situation, the server for the purposes of conformance is such a situation, the server for the purposes of this specification
considered to include all parts of the server-side infrastructure is considered to include all parts of the server-side infrastructure
from the first device to terminate the TCP connection all the way to from the first device to terminate the TCP connection all the way to
the server that processes requests and sends responses. the server that processes requests and sends responses.
EXAMPLE: For example, a data center might have a server that responds EXAMPLE: For example, a data center might have a server that responds
to WebSocket requests with an appropriate handshake, and then passes to WebSocket requests with an appropriate handshake, and then passes
the connection to another server to actually process the data frames. the connection to another server to actually process the data frames.
For the purposes of this specification, the "server" is the For the purposes of this specification, the "server" is the
combination of both computers. combination of both computers.
4.2.1. Reading the Client's Opening Handshake 4.2.1. Reading the Client's Opening Handshake
skipping to change at page 23, line 44 skipping to change at page 23, line 44
3. An "Upgrade" header field containing the value "websocket", 3. An "Upgrade" header field containing the value "websocket",
treated as an ASCII case-insensitive value. treated as an ASCII case-insensitive value.
4. A "Connection" header field that includes the token "Upgrade", 4. A "Connection" header field that includes the token "Upgrade",
treated as an ASCII case-insensitive value. treated as an ASCII case-insensitive value.
5. A "Sec-WebSocket-Key" header field with a base64-encoded (see 5. A "Sec-WebSocket-Key" header field with a base64-encoded (see
Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in
length. length.
6. A "Sec-WebSocket-Version" header field, with a value of 8. 6. A "Sec-WebSocket-Version" header field, with a value of 13.
7. Optionally, a "Origin" header field. This header field is sent 7. Optionally, an "Origin" header field. This header field is sent
by all browser clients. A connection attempt lacking this by all browser clients. A connection attempt lacking this
header field SHOULD NOT be interpreted as coming from a browser header field SHOULD NOT be interpreted as coming from a browser
client. client.
8. Optionally, a "Sec-WebSocket-Protocol" header field, with a list 8. Optionally, a "Sec-WebSocket-Protocol" header field, with a list
of values indicating which protocols the client would like to of values indicating which protocols the client would like to
speak, ordered by preference. speak, ordered by preference.
9. Optionally, a "Sec-WebSocket-Extensions" header field, with a 9. Optionally, a "Sec-WebSocket-Extensions" header field, with a
list of values indicating which extensions the client would like list of values indicating which extensions the client would like
skipping to change at page 24, line 21 skipping to change at page 24, line 21
10. Optionally, other header fields, such as those used to send 10. Optionally, other header fields, such as those used to send
cookies or request authentication to a server. Unknown header cookies or request authentication to a server. Unknown header
fields are ignored, as per [RFC2616]. fields are ignored, as per [RFC2616].
4.2.2. Sending the Server's Opening Handshake 4.2.2. Sending the Server's Opening Handshake
When a client establishes a WebSocket connection to a server, the When a client establishes a WebSocket connection to a server, the
server MUST complete the following steps to accept the connection and server MUST complete the following steps to accept the connection and
send the server's opening handshake. send the server's opening handshake.
1. If the server supports encryption, perform a TLS handshake over 1. If the connection is happening on an HTTPS (HTTP-over-TLS) port,
the connection. If this fails (e.g. the client indicated a host perform a TLS handshake over the connection. If this fails (e.g.
name in the extended client hello "server_name" extension that the client indicated a host name in the extended client hello
the server does not host), then close the connection; otherwise, "server_name" extension that the server does not host), then
all further communication for the connection (including the close the connection; otherwise, all further communication for
server's handshake) MUST run through the encrypted tunnel. the connection (including the server's handshake) MUST run
[RFC5246] through the encrypted tunnel. [RFC5246]
2. If the server wishes to perform additional client authentication, 2. The server can perform additional client authentication, for
it might return 401 status code with the corresponding WWW- example by returning a 401 status code with the corresponding
Authenticate header field as described in [RFC2616]. WWW-Authenticate header field as described in [RFC2616].
3. The server MAY redirect the client using a 3xx status code 3. The server MAY redirect the client using a 3xx status code
[RFC2616]. Note that this step can happen together with, before [RFC2616]. Note that this step can happen together with, before
or after the optional authentication step described above. or after the optional authentication step described above.
4. Establish the following information: 4. Establish the following information:
/origin/ /origin/
The |Origin| header field in the client's handshake indicates The |Origin| header field in the client's handshake indicates
the origin of the script establishing the connection. The the origin of the script establishing the connection. The
skipping to change at page 26, line 39 skipping to change at page 26, line 39
4. A "Sec-WebSocket-Accept" header field. The value of this 4. A "Sec-WebSocket-Accept" header field. The value of this
header field is constructed by concatenating /key/, defined header field is constructed by concatenating /key/, defined
above in Paragraph 4 of Section 4.2.2, with the string above in Paragraph 4 of Section 4.2.2, with the string
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash
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 of this header field is defined as follows: The ABNF of this header field is defined as follows:
Sec-WebSocket-Accept = base64-value Sec-WebSocket-Accept = base64-value-non-empty
base64-value-non-empty = (1*base64-data [ base64-padding ]) |
base64-padding
base64-value = *base64-data [ 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
skipping to change at page 27, line 17 skipping to change at page 27, line 19
value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned
in the "Sec-WebSocket-Accept" header field. in the "Sec-WebSocket-Accept" header field.
5. Optionally, a "Sec-WebSocket-Protocol" header field, with a 5. Optionally, a "Sec-WebSocket-Protocol" header field, with a
value /subprotocol/ as defined in Paragraph 4 of value /subprotocol/ as defined in Paragraph 4 of
Section 4.2.2. Section 4.2.2.
6. Optionally, a "Sec-WebSocket-Extensions" header field, with a 6. Optionally, a "Sec-WebSocket-Extensions" header field, with a
value /extensions/ as defined in Paragraph 4 of value /extensions/ as defined in Paragraph 4 of
Section 4.2.2. If multiple extensions are to be used, they Section 4.2.2. If multiple extensions are to be used, they
must all be listed in a single Sec-WebSocket-Extensions can all be listed in a single Sec-WebSocket-Extensions header
header field. This header field MUST NOT be repeated. field, or split between multiple instances of the Sec-
WebSocket-Extensions header field.
This completes the server's handshake. If the server finishes these This completes the server's handshake. If the server finishes these
steps without aborting the WebSocket handshake, the server considers steps without aborting the WebSocket handshake, the server considers
the WebSocket connection to be established and that the WebSocket the WebSocket connection to be established and that the WebSocket
connection is in the OPEN state. At this point, the server may begin connection is in the OPEN state. At this point, the server may begin
sending (and receiving) data. sending (and receiving) data.
4.3. Collected ABNF for new header fields used in handshake 4.3. Collected ABNF for new header fields used in handshake
Unlike other section of the document this section is using ABNF Unlike other sections of the document this section is using ABNF
syntax/rules from Section 2.1 of [RFC2616], including "implied *LWS syntax/rules from Section 2.1 of [RFC2616], including "implied *LWS
rule". rule".
Note that the following ABNF conventions are used in this section: Note that the following ABNF conventions are used in this section:
Some names of the rules correspond to names of the corresponding Some names of the rules correspond to names of the corresponding
header fields. Such rules express values of the corresponding header header fields. Such rules express values of the corresponding header
fields, for example the Sec-WebSocket-Key ABNF rule describes syntax fields, for example the Sec-WebSocket-Key ABNF rule describes syntax
of the Sec-WebSocket-Key header field value. ABNF rules with the of the Sec-WebSocket-Key header field value. ABNF rules with the
"-Client" suffix in the name are only used in requests sent by the "-Client" suffix in the name are only used in requests sent by the
client to the server; ABNF rules with the "-Server" suffix in the client to the server; ABNF rules with the "-Server" suffix in the
name are only used in responses sent by the server to the client. name are only used in responses sent by the server to the client.
For example, the ABNF rule Sec-WebSocket-Protocol-Client describes For example, the ABNF rule Sec-WebSocket-Protocol-Client describes
syntax of the Sec-WebSocket-Protocol header field value sent by the syntax of the Sec-WebSocket-Protocol header field value sent by the
client to the server. client to the server.
The following new header field can be sent during the handshake from The following new header field can be sent during the handshake from
the client to the server: the client to the server:
Sec-WebSocket-Key = base64-value Sec-WebSocket-Key = base64-value-non-empty
Sec-WebSocket-Extensions = extension-list Sec-WebSocket-Extensions = extension-list
Sec-WebSocket-Protocol-Client = 1#token Sec-WebSocket-Protocol-Client = 1#token
Sec-WebSocket-Version-Client = version Sec-WebSocket-Version-Client = version
base64-value = *base64-data [ base64-padding ] base64-value-non-empty = (1*base64-data [ base64-padding ]) |
base64-data = 4base64-character base64-padding
base64-padding = (2base64-character "==") | base64-data = 4base64-character
(3base64-character "=") base64-padding = (2base64-character "==") |
base64-character = ALPHA | DIGIT | "+" | "/" (3base64-character "=")
extension-list = 1#extension base64-character = ALPHA | DIGIT | "+" | "/"
extension = extension-token *( ";" extension-param ) extension-list = 1#extension
extension-token = registered-token extension = extension-token *( ";" extension-param )
registered-token = token extension-token = registered-token
extension-param = token [ "=" token ] registered-token = token
NZDIGIT = "1" | "2" | "3" | "4" | "5" | "6" | extension-param = token [ "=" (token | quoted-string) ]
"7" | "8" | "9" ;When using the quoted-string syntax variant, the value
version = DIGIT | (NZDIGIT DIGIT) | ;after quoted-string unescaping MUST conform to the 'token' ABNF.
("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) NZDIGIT = "1" | "2" | "3" | "4" | "5" | "6" |
; Limited to 0-255 range, with no leading zeros "7" | "8" | "9"
version = DIGIT | (NZDIGIT DIGIT) |
("1" DIGIT DIGIT) | ("2" DIGIT DIGIT)
; Limited to 0-255 range, with no leading zeros
The following new header field can be sent during the handshake from The following new header field can be sent during the handshake from
the server to the client: the server to the client:
Sec-WebSocket-Extensions = extension-list Sec-WebSocket-Extensions = extension-list
Sec-WebSocket-Accept = base64-value Sec-WebSocket-Accept = base64-value-non-empty
Sec-WebSocket-Protocol-Server = token Sec-WebSocket-Protocol-Server = token
Sec-WebSocket-Version-Server = 1#version Sec-WebSocket-Version-Server = 1#version
4.4. Supporting multiple versions of WebSocket protocol
This section provides some guidance on supporting multiple versions
of the WebSocket protocol in clients and servers.
Using the WebSocket version advertisement capability (the "Sec-
WebSocket-Version" header field) client can initially request the
version of the WebSocket protocol that it prefers (which doesn't
necessarily have to be the latest supported by the client). If the
server supports the requested version and the handshake message is
otherwise valid, the server will accept that version. If the server
doesn't support the requested version, it will respond with a Sec-
WebSocket-Version header field (or multiple Sec-WebSocket-Version
header fields) containing all versions it is willing to use. At this
point, if the client supports one of the advertised versions, it can
repeat the WebSocket handshake using a new version value.
The following example demonstrates version negotiation described
above:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
...
Sec-WebSocket-Version: 25
The response from the server might look as follows:
HTTP/1.1 400 Bad Request
...
Sec-WebSocket-Version: 13, 8, 7
Note that the last response from the server might also look like:
HTTP/1.1 400 Bad Request
...
Sec-WebSocket-Version: 13
Sec-WebSocket-Version: 8, 7
The client now repeats the handshake that conforms to version 13:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
...
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. All frames sent from the client to the server are masked to frames. All frames sent from the client to the server are masked to
avoid confusing network intermediaries, such as intercepting proxies. avoid confusing network intermediaries, such as intercepting proxies.
All frames sent from the server to the client are not masked. All frames sent from the server to the client are not masked.
The base framing protocol defines a frame type with an opcode, a The base framing protocol defines a frame type with an opcode, a
skipping to change at page 31, line 5 skipping to change at page 32, line 5
the payload data as per Section 5.3. All frames sent from client the payload data as per Section 5.3. All frames sent from client
to server have this bit set to 1. to server have this bit set to 1.
Payload length: 7 bits, 7+16 bits, or 7+64 bits Payload length: 7 bits, 7+16 bits, or 7+64 bits
The length of the payload data, in bytes: if 0-125, that is the The length of the payload data, in bytes: if 0-125, that is the
payload length. If 126, the following 2 bytes interpreted as a 16 payload length. If 126, the following 2 bytes interpreted as a 16
bit unsigned integer are the payload length. If 127, the bit unsigned integer are the payload length. If 127, the
following 8 bytes interpreted as a 64-bit unsigned integer (the following 8 bytes interpreted as a 64-bit unsigned integer (the
most significant bit MUST be 0) are the payload length. Multibyte most significant bit MUST be 0) are the payload length. Multibyte
length quantities are expressed in network byte order. The length quantities are expressed in network byte order. Note that
payload length is the length of the extension data + the length of in all case the minimal number of bytes MUST be used to encode the
the application data. The length of the extension data may be length, for example the length of a 124 byte long string can't be
zero, in which case the payload length is the length of the encoded as the sequence 126, 0, 124. The payload length is the
application data. length of the extension data + the length of the application data.
The length of the extension data may be zero, in which case the
payload length is the length of the application data.
Masking-key: 0 or 4 bytes Masking-key: 0 or 4 bytes
All frames sent from the client to the server are masked by a 32- All frames sent from the client to the server are masked by a 32-
bit value that is contained within the frame. This field is bit value that is contained within the frame. This field is
present if the mask bit is set to 1, and is absent if the mask bit present if the mask bit is set to 1, and is absent if the mask bit
is set to 0. See Section 5.3 for further information on client- is set to 0. See Section 5.3 for further information on client-
to-server masking. to-server masking.
Payload data: (x+y) bytes Payload data: (x+y) bytes
skipping to change at page 32, line 8 skipping to change at page 33, line 18
frame-rsv3 frame-rsv3
frame-opcode frame-opcode
frame-masked frame-masked
frame-payload-length frame-payload-length
[ frame-masking-key ] [ frame-masking-key ]
frame-payload-data frame-payload-data
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
frame-rsv1 = %x0 frame-rsv1 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-rsv2 = %x0 frame-rsv2 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-rsv3 = %x0 frame-rsv3 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-opcode = %x0 ; continuation frame frame-opcode = %x0 ; continuation frame
/ %x1 ; text frame / %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
/ %x8 ; connection close / %x8 ; connection close
/ %x9 ; ping / %x9 ; ping
skipping to change at page 34, line 26 skipping to change at page 35, line 34
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
be counted before first byte is sent. With fragmentation, a server be counted before first byte is sent. With fragmentation, a server
or intermediary may choose a reasonable size buffer, and when the or intermediary may choose a reasonable size buffer, and when the
buffer is full write a fragment to the network. buffer is full write a fragment to the network.
A secondary use-case for fragmentation is for multiplexing, where it A secondary use-case for fragmentation is for multiplexing, where it
is not desirable for a large message on one logical channel to is not desirable for a large message on one logical channel to
monopolize the output channel, so the MUX needs to be free to split monopolize the output channel, so the MUX needs to be free to split
the message into smaller fragments to better share the output the message into smaller fragments to better share the output
channel. channel. (Note that the multiplexing extension is not described in
this document.)
Unless specified otherwise by an extension, frames have no semantic Unless specified otherwise by an extension, frames have no semantic
meaning. An intermediary might coalesce and/or split frames, if no meaning. An intermediary might coalesce and/or split frames, if no
extensions were negotiated by the client and the server, or if some extensions were negotiated by the client and the server, or if some
extensions were negotiated, but the intermediary understood all the extensions were negotiated, but the intermediary understood all the
extensions negotiated and knows how to coalesce and/or split frames extensions negotiated and knows how to coalesce and/or split frames
in presence of these extensions. One implication of this is that in in presence of these extensions. One implication of this is that in
absence of extensions senders and receivers must not depend on absence of extensions senders and receivers must not depend on
presence of specific frame boundaries. presence of specific frame boundaries.
skipping to change at page 36, line 12 skipping to change at page 37, line 23
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
fragmented message._ fragmented message._
_Implementation Note: in absence of any extension a receiver doesn't _Implementation Note: in absence of any extension a receiver doesn't
have to buffer the whole frame in order to process it. For example have to buffer the whole frame in order to process it. For example
if streaming API is used, a part of a frame can be delivered to the if a streaming API is used, a part of a frame can be delivered to the
application. But note that that assumption might not hold true for application. But note that that assumption might not hold true for
all future WebSocket extensions._ all future WebSocket extensions._
5.5. Control Frames 5.5. Control Frames
Control frames are identified by opcodes where the most significant Control frames are identified by opcodes where the most significant
bit of the opcode is 1. Currently defined opcodes for control frames bit of the opcode is 1. Currently defined opcodes for control frames
include 0x8 (Close), 0x9 (Ping), and 0xA (Pong). Opcodes 0xB-0xF are include 0x8 (Close), 0x9 (Ping), and 0xA (Pong). Opcodes 0xB-0xF are
reserved for further control frames yet to be defined. reserved for further control frames yet to be defined.
skipping to change at page 37, line 32 skipping to change at page 38, line 43
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,
both endpoints will have sent and received a Close message and should both endpoints will have sent and received a Close message and should
consider the WebSocket connection closed and close the underlying TCP consider the WebSocket connection closed and close the underlying TCP
connection. connection.
5.5.2. Ping 5.5.2. Ping
The Ping frame contains an opcode of 0x9. The Ping frame contains an opcode of 0x9.
A Ping frame MAY include Application Data.
Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in
response. It SHOULD do so as soon as is practical. Pong frames are response, unless it already received a Close frame. It SHOULD
respond with Pong frame as soon as is practical. Pong frames are
discussed in Section 5.5.3. discussed in Section 5.5.3.
An endpoint MAY send a Ping frame any time after the connection is An endpoint MAY send a Ping frame any time after the connection is
established and before the connection is closed. NOTE: A ping frame established and before the connection is closed. NOTE: A ping frame
may serve either as a keepalive, or to verify that the remote may serve either as a keepalive, or to verify that the remote
endpoint is still responsive. endpoint is still responsive.
5.5.3. Pong 5.5.3. Pong
The Pong frame contains an opcode of 0xA. The Pong frame contains an opcode of 0xA.
skipping to change at page 38, line 39 skipping to change at page 40, line 7
however the whole message MUST contain valid UTF-8. Invalid UTF-8 however the whole message MUST contain valid UTF-8. Invalid UTF-8
in reassembled messages is handled as described in Section 8.1. in reassembled messages is handled as described in Section 8.1.
Binary Binary
The payload data is arbitrary binary data whose interpretation is The payload data is arbitrary binary data whose interpretation is
solely up to the application layer. solely up to the application layer.
5.7. Examples 5.7. Examples
_This section is non-normative._
o A single-frame unmasked text message o A single-frame unmasked text message
* 0x81 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello") * 0x81 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello")
o A single-frame masked text message o A single-frame masked text message
* 0x81 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 * 0x81 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58
(contains "Hello") (contains "Hello")
o A fragmented unmasked text message o A fragmented unmasked text message
skipping to change at page 39, line 27 skipping to change at page 40, line 41
* 0x82 0x7E 0x0100 [256 bytes of binary data] * 0x82 0x7E 0x0100 [256 bytes of binary data]
o 64KiB binary message in a single unmasked frame o 64KiB binary message in a single unmasked frame
* 0x82 0x7F 0x0000000000010000 [65536 bytes of binary data] * 0x82 0x7F 0x0000000000010000 [65536 bytes of binary data]
5.8. Extensibility 5.8. Extensibility
The protocol is designed to allow for extensions, which will add The protocol is designed to allow for extensions, which will add
capabilities to the base protocols. The endpoints of a connection capabilities to the base protocol. The endpoints of a connection
MUST negotiate the use of any extensions during the opening MUST negotiate the use of any extensions during the opening
handshake. This specification provides opcodes 0x3 through 0x7 and handshake. This specification provides opcodes 0x3 through 0x7 and
0xB through 0xF, the extension data field, and the frame-rsv1, frame- 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. rsv2, and frame-rsv3 bits of the frame header for use by extensions.
The negotiation of extensions is discussed in further detail in The negotiation of extensions is discussed in further detail in
Section 9.1. Below are some anticipated uses of extensions. This Section 9.1. Below are some anticipated uses of extensions. This
list is neither complete nor prescriptive. list is neither complete nor prescriptive.
o Extension data may be placed in the payload data before the o Extension data may be placed in the payload data before the
application data. application data.
skipping to change at page 45, line 22 skipping to change at page 47, line 22
Abnormal closures may be caused by any number of reasons. Such Abnormal closures may be caused by any number of reasons. Such
closures could be the result of a transient error, in which case closures could be the result of a transient error, in which case
reconnecting may lead to a good connection and a resumption of normal reconnecting may lead to a good connection and a resumption of normal
operations. Such closures may also be the result of a nontransient operations. Such closures may also be the result of a nontransient
problem, in which case if each deployed client experiences an problem, in which case if each deployed client experiences an
abnormal closure and immediately and persistently tries to reconnect, abnormal closure and immediately and persistently tries to reconnect,
the server may experience what amounts to a denial of service attack the server may experience what amounts to a denial of service attack
by a large number of clients trying to reconnect. The end result of by a large number of clients trying to reconnect. The end result of
such a scenario could be that the service is unable to recover, or such a scenario could be that the service is unable to recover, or
recovey is made much more difficult, in any sort of timely manner. recovery is made much more difficult, in any sort of timely manner.
To prevent this, clients SHOULD use some form of backoff when trying To prevent this, clients SHOULD use some form of backoff when trying
to reconnect after abnormal closures as described in this section. to reconnect after abnormal closures as described in this section.
The first reconnect attempt SHOULD be delayed by a random amount of The first reconnect attempt SHOULD be delayed by a random amount of
time. The parameters by which this random delay is chosen are left time. The parameters by which this random delay is chosen are left
to the client to decide; a value chosen randomly between 0 and 5 to the client to decide; a value chosen randomly between 0 and 5
seconds is a reasonable initial delay though clients MAY choose a seconds is a reasonable initial delay though clients MAY choose a
different interval from which to select a delay length based on different interval from which to select a delay length based on
implementation experience and particular application. implementation experience and particular application.
skipping to change at page 47, line 9 skipping to change at page 49, line 9
1006 is a reserved value and MUST NOT be set as a status code in a 1006 is a reserved value and MUST NOT be set as a status code in a
Close control frame by an endpoint. It is designated for use in Close control frame by an endpoint. It is designated for use in
applications expecting a status code to indicate that the applications expecting a status code to indicate that the
connection was closed abnormally, e.g. without sending or connection was closed abnormally, e.g. without sending or
receiving a Close control frame. receiving a Close control frame.
1007 1007
1007 indicates that an endpoint is terminating the connection 1007 indicates that an endpoint is terminating the connection
because it has received data that was supposed to be UTF-8 (such because it has received data within a message that was not
as in a text frame) that was in fact not valid UTF-8 [RFC3629]. consistent with the type of the message (e.g., non-UTF-8 [RFC3629]
data within a text message).
1008 1008
1008 indicates that an endpoint is terminating the connection 1008 indicates that an endpoint is terminating the connection
because it has received a message that violates its policy. This because it has received a message that violates its policy. This
is a generic status code that can be returned when there is no is a generic status code that can be returned when there is no
other more suitable status code (e.g. 1003 or 1009), or if there other more suitable status code (e.g. 1003 or 1009), or if there
is a need to hide specific details about the policy. is a need to hide specific details about the policy.
1009 1009
skipping to change at page 50, line 21 skipping to change at page 52, line 21
between the client and the server, those parameters MUST be chosen in between the client and the server, those parameters MUST be chosen in
accordance with the specification of the extension to which the accordance with the specification of the extension to which the
parameters apply. parameters apply.
9.1. Negotiating Extensions 9.1. Negotiating Extensions
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. Note that unlike other field is defined by the following ABNF. Note that unlike other
section of the document this section is using ABNF syntax/rules from sections of the document this section is using ABNF syntax/rules from
[RFC2616], including "implied *LWS rule". If a value is received by [RFC2616], including "implied *LWS rule". If a value is received by
either the client or the server during negotiation that does not either the client or the server during negotiation that does not
conform to the ABNF below, the recipient of such malformed data MUST conform to the ABNF below, the recipient of such malformed data MUST
immediately _Fail the WebSocket Connection_. immediately _Fail the 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 ] extension-param = token [ "=" (token | quoted-string) ]
;When using the quoted-string syntax variant, the value
;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 51, line 18 skipping to change at page 53, line 21
listed by the server in response represent the extensions actually in listed by the server in response represent the extensions actually in
use for the connection. Should the extensions modify the data and/or use for the connection. Should the extensions modify the data and/or
framing, the order of operations on the data should be assumed to be framing, the order of operations on the data should be assumed to be
the same as the order in which the extensions are listed in the the same as the order in which the extensions are listed in the
server's response in the opening handshake. server's response in the opening handshake.
For example, if there are two extensions "foo" and "bar", if the For example, if there are two extensions "foo" and "bar", if the
header field |Sec-WebSocket-Extensions| sent by the server has the header field |Sec-WebSocket-Extensions| sent by the server has the
value "foo, bar" then operations on the data will be made as value "foo, bar" then operations on the data will be made as
bar(foo(data)), be those changes to the data itself (such as bar(foo(data)), be those changes to the data itself (such as
compression) or changes to the framing thay may "stack". compression) or changes to the framing that may "stack".
Non-normative examples of acceptable extension header fields (note Non-normative examples of acceptable extension header fields (note
that long lines are folded for readability): that long lines are folded for readability):
Sec-WebSocket-Extensions: deflate-stream Sec-WebSocket-Extensions: deflate-stream
Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, Sec-WebSocket-Extensions: mux; max-channels=4; flow-control,
deflate-stream deflate-stream
Sec-WebSocket-Extensions: private-extension Sec-WebSocket-Extensions: private-extension
A server accepts one or more extensions by including a |Sec- A server accepts one or more extensions by including a |Sec-
skipping to change at page 52, line 17 skipping to change at page 54, line 17
This section describes some security considerations applicable to the This section describes some security considerations applicable to the
WebSocket protocol. Specific security considerations are described WebSocket protocol. Specific security considerations are described
in subsections of this section. in subsections of this section.
10.1. Non-Browser Clients 10.1. Non-Browser Clients
Many threats anticipated by the WebSocket protocol protect from Many threats anticipated by the WebSocket protocol protect from
malicious JavaScript running inside a trusted application such as a malicious JavaScript running inside a trusted application such as a
web browser, for example checking of the "Origin" header field (see web browser, for example checking of the "Origin" header field (see
below). See Section 1.6 for additional details. Such assumptions below). See Section 1.6 for additional details. Such assumptions
don't hold true in a case of a more capable client. don't hold true in the case of a more capable client.
While this protocol is intended to be used by scripts in Web pages, While this protocol is intended to be used by scripts in Web pages,
it can also be used directly by hosts. Such hosts are acting on it can also be used directly by hosts. Such hosts are acting on
their own behalf, and can therefore send fake "Origin" header fields, their own behalf, and can therefore send fake "Origin" header fields,
misleading the server. Servers should therefore be careful about misleading the server. Servers should therefore be careful about
assuming that they are talking directly to scripts from known assuming that they are talking directly to scripts from known
origins, and must consider that they might be accessed in unexpected origins, and must consider that they might be accessed in unexpected
ways. In particular, a server should not trust that any input is ways. In particular, a server should not trust that any input is
valid. valid.
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, and should only respond with the corresponding "Sec- they expect. If the origin indicated is unacceptable to the server,
WebSocket-Accept" if it is an accepted origin. then it SHOULD respond to the WebSocket handshake with a reply
containing HTTP 403 Unauthorized 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.
10.3. Attacks On Infrastructure (Masking) 10.3. Attacks On Infrastructure (Masking)
In addition to endpoints being the target of attacks via WebSockets, In addition to endpoints being the target of attacks via WebSockets,
other parts of web infrastructure, such as proxies, may be the other parts of web infrastructure, such as proxies, may be the
subject of an attack. subject of an attack.
As this protocol was being developed, an experiment was conducted to As this protocol was being developed, an experiment was conducted to
demonstrate a class of attacks on proxies that led to the poisoning demonstrate a class of attacks on proxies that led to the poisoning
of caching proxies deployed in the wild. The general form of the of caching proxies deployed in the wild [TALKING]. The general form
attack was to establish a connection to a server under the of the attack was to establish a connection to a server under the
"attacker's" control, perform an UPGRADE on the HTTP connection "attacker's" control, perform an UPGRADE on the HTTP connection
similar to what the WebSocket protocol does to establish a similar to what the WebSocket protocol does to establish a
connection, and to subsequently send data over that UPGRADEd connection, and to subsequently send data over that UPGRADEd
connection that looked like a GET request for a specific known connection that looked like a GET request for a specific known
resource (which in an attack would likely be something like a widely resource (which in an attack would likely be something like a widely
deployed script for tracking hits, or a resource on an ad-serving deployed script for tracking hits, or a resource on an ad-serving
network). The remote server would respond with something that looked network). The remote server would respond with something that looked
like a response to the fake GET request, and this response would be like a response to the fake GET request, and this response would be
cached by a nonzero percentage of deployed intermediaries, thus cached by a nonzero percentage of deployed intermediaries, thus
poisioning the cache. The net effect of this attack would be that if poisioning the cache. The net effect of this attack would be that if
a user could be convinced to visit a website the attacker controlled, a user could be convinced to visit a website the attacker controlled,
the attacker could potentially poison the cache for that user and the attacker could potentially poison the cache for that user and
other users behind the same cache and run malicious script on other other users behind the same cache and run malicious script on other
origins, compromising the web security model. origins, compromising the web security model.
To avoid such attacks on deployed intermediaries, the working group To avoid such attacks on deployed intermediaries, it is not
decided to adopt a solution that would provably protect against such sufficient to prefix application supplied data with framing that is
attacks. There were many proposed solutions that people argued not compliant HTTP, as it is not possible to exhaustively discover
"should" protect against the above attacks, such as adding in more and test that each nonconformant intermediary does not skip such non
random data and null bytes to the handshake, starting each frame with HTTP framing and act incorrectly on the frame payload. Thus the
a byte that has the first (highest order) bit set such that the data defence adopted is to mask all data from the client to the server, so
appears to be non-ASCII, and so forth, but in the end none of these that the remote script (attacker) does not have control over how the
solutions were provably secure. The deployed intermediaries were data being sent appears on the wire, and thus cannot construct a
already not conforming to existing specifications, and given that we message that could be misinterpreted by an intermediary as an HTTP
can't possibly enumerate all of the ways in which such request.
nonconformities could exhibit themselves and that we cannot
exhaustively discover and test each nonconformant intermediary
against each possible attack, there was consensus to adopt an
approach that did not require people to reason about how
nonconformant intermediaries might behave. Namely, the working group
decided to mask all data from the client to the server, so that the
remote script (attacker) does not have control over how the data
being sent appears on the wire, and thus cannot construct a message
that could be mis- interpreted by an intermediary as an HTTP request.
It is necessary that the masking key is chosen randomly for each Clients MUST choose a new masking key for each frame, using an
frame. If the same key is used, or a decipherable pattern exists for algorithm that cannot be predicted by end applications that provide
how the next key is chosen, the attacker can send a message that, data. For example, each masking could be drawn from a
when masked, could appear to be an HTTP request (by taking the cryptographically strong random number generator. If the same key is
message the attacker wishes to see on the wire, and masking it with used, or a decipherable pattern exists for how the next key is
the next masking key to be used, when the client applies the masking chosen, the attacker can send a message that, when masked, could
key it will effectively unmask the data.) appear to be an HTTP request (by taking the message the attacker
wishes to see on the wire, and masking it with the next masking key
to be used, when the client applies the masking key it will
effectively unmask the data.)
It is also necessary that once the transmission of a frame from a It is also necessary that once the transmission of a frame from a
client has begun, the payload (application supplied data) of that client has begun, the payload (application supplied data) of that
frame must not be capable of being modified by the application. frame must not be capable of being modified by the application.
Otherwise, an attacker could send a long frame where the initial data Otherwise, an attacker could send a long frame where the initial data
was a known value (such as all zeros), compute the masking key being was a known value (such as all zeros), compute the masking key being
used upon receipt of the first part of the data, and then modify the used upon receipt of the first part of the data, and then modify the
data that is yet to be sent in the frame to appear as an HTTP request data that is yet to be sent in the frame to appear as an HTTP request
when masked. (This is essentially the same problem described in the when masked. (This is essentially the same problem described in the
previous paragraph with using a known or predictable masking key.) previous paragraph with using a known or predictable masking key.)
skipping to change at page 54, line 29 skipping to change at page 56, line 23
changed, that new or changed data must be sent in a new frame and changed, that new or changed data must be sent in a new frame and
thus with a new masking key. In short, once transmission of a frame thus with a new masking key. In short, once transmission of a frame
begins, the contents must not be modifiable by the remote script begins, the contents must not be modifiable by the remote script
(application). (application).
The threat model being protected against is one in which the client The threat model being protected against is one in which the client
sends data that appears to be a HTTP request. As such, the channel sends data that appears to be a HTTP request. As such, the channel
that needs to be masked is the data from the client to the server. that needs to be masked is the data from the client to the server.
The data from the server to the client can be made to look like a The data from the server to the client can be made to look like a
response, but to accomplish this request the client must also be able response, but to accomplish this request the client must also be able
to forge a request. As such, it was not deemend 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
proxies will still be vulnerable to poisoning attacks of this type by
clients and servers that do not apply masking.
10.4. Implementation-Specific Limits 10.4. Implementation-Specific Limits
Implementations MAY impose implementation-specific limits on Implementations MUST impose implementation-specific limits on
otherwise unconstrained inputs, e.g. to prevent denial of service otherwise unconstrained inputs, e.g. to prevent denial of service
attacks, to guard against running out of memory, or to work around attacks, to guard against running out of memory, or to work around
platform-specific limitations. For example implementations might platform-specific limitations. In particular, a malicious endpoint
impose limit on frame sizes and the total message size after can try to exhaust its peer memory by sending either a single big
reassembly from multiple frames. frame (e.g. of size 2**60), or by sending a long stream of small
frames which are a part of a fragmented message. In order to protect
from this implementations SHOULD impose limit on frame sizes 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, 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
Communications confidentiality and integrity is provided by running Communications confidentiality and integrity is provided by running
the WebSocket protocol over TLS (wss URIs). the WebSocket protocol over TLS (wss URIs). WebSocket
implementations MUST support TLS, and SHOULD employ it when
communicating with their peers.
For connections using TLS, the amount of benefit provided by TLS For connections using TLS, the amount of benefit provided by TLS
depends greatly on the strength of the algorithms negotiated during depends greatly on the strength of the algorithms negotiated during
the TLS handshake. For example some TLS cipher mechanisms don't the TLS handshake. For example some TLS cipher mechanisms don't
provide connection confidentiality. To achieve reasonable levels of provide connection confidentiality. To achieve reasonable levels of
protections, clients should use only Strong TLS algorithms. "Web protections, clients should use only Strong TLS algorithms. "Web
Security Context: User Interface Guidelines" Security Context: User Interface Guidelines"
[W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS [W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS
algorithms. algorithms. [RFC5246] provides additional guidance in Appendix A.5
and Appendix D.3.
10.7. Handling of invalid data 10.7. Handling of invalid data
Incoming data MUST always be validated by both clients and servers. Incoming data MUST always be validated by both clients and servers.
If at any time an endpoint is faced with data that it does not If at any time an endpoint is faced with data that it does not
understand, or that violates some criteria by which the endpoint understand, or that violates some criteria by which the endpoint
determines safety of input, or when the endpoint sees an opening determines safety of input, or when the endpoint sees an opening
handshake that does not correspond to the values it is expecting handshake that does not correspond to the values it is expecting
(e.g. incorrect path or origin in the client request), the endpoint (e.g. incorrect path or origin in the client request), the endpoint
MAY drop the TCP connection. If the invalid data received after a MAY drop the TCP connection. If the invalid data received after a
skipping to change at page 56, line 5 skipping to change at page 57, line 48
A common class of security problems arise when sending text data A common class of security problems arise when sending text data
using using the wrong encoding. This protocol specifies that using using the wrong encoding. This protocol specifies that
messages with a Text data type (as opposed to Binary or other types) messages with a Text data type (as opposed to Binary or other types)
contain UTF-8 encoded data. Although the length is still indicated contain UTF-8 encoded data. Although the length is still indicated
and applications implementing this protocol should use the length to and applications implementing this protocol should use the length to
determine where the frame actually ends, sending data in an improper determine where the frame actually ends, sending data in an improper
encoding may still break assumptions applications built on top of encoding may still break assumptions applications built on top of
this protocol may make, leading from anything to misinterpretation of this protocol may make, leading from anything to misinterpretation of
data to loss of data to potential security bugs. data to loss of data to potential security bugs.
10.8. Use of SHA-1 by the WebSocket protocol
The protocol described in this document doesn't depend on any
security properties of SHA-1, such as collision resistence or
resistence to the second pre-image attack (as described in
[RFC4270]).
11. IANA Considerations 11. IANA Considerations
11.1. Registration of new URI Schemes 11.1. Registration of new URI Schemes
11.1.1. Registration of "ws" Scheme 11.1.1. Registration of "ws" Scheme
A |ws| URI identifies a WebSocket server and resource name. A |ws| URI identifies a WebSocket server and resource name.
URI scheme name. URI scheme name.
ws ws
skipping to change at page 59, line 30 skipping to change at page 62, line 30
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Key| header field is used in the WebSocket opening The |Sec-WebSocket-Key| header field is used in the WebSocket opening
handshake. It is sent from the client to the server to provide part handshake. It is sent from the client to the server to provide part
of the information used by the server to prove that it received a of the information used by the server to prove that it received a
valid WebSocket opening handshake. This helps ensure that the server valid WebSocket opening handshake. This helps ensure that the server
does not accept connections from non-WebSocket clients (e.g. HTTP does not accept connections from non-WebSocket clients (e.g. HTTP
clients) that are being abused to send data to unsuspecting WebSocket clients) that are being abused to send data to unsuspecting WebSocket
servers. servers.
The |Sec-WebSocket-Key| header field MUST NOT appear more than once
in an HTTP request.
11.3.2. Sec-WebSocket-Extensions 11.3.2. Sec-WebSocket-Extensions
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Extensions Sec-WebSocket-Extensions
Applicable protocol Applicable protocol
http http
skipping to change at page 60, line 14 skipping to change at page 63, line 17
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Extensions| header field is used in the WebSocket The |Sec-WebSocket-Extensions| header field is used in the WebSocket
opening handshake. It is initially sent from the client to the opening handshake. It is initially sent from the client to the
server, and then subsequently sent from the server to the client, to server, and then subsequently sent from the server to the client, to
agree on a set of protocol-level extensions to use for the duration agree on a set of protocol-level extensions to use for the duration
of the connection. of the connection.
The |Sec-WebSocket-Extensions| header field MAY appear multiple times
in an HTTP request (which is logically the same as a single |Sec-
WebSocket-Extensions| header field that contains all values. However
the |Sec-WebSocket-Extensions| header field MUST NOT appear more than
once in an HTTP response.
11.3.3. Sec-WebSocket-Accept 11.3.3. Sec-WebSocket-Accept
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Accept Sec-WebSocket-Accept
Applicable protocol Applicable protocol
http http
skipping to change at page 60, line 39 skipping to change at page 63, line 48
IETF IETF
Specification document(s) Specification document(s)
RFC XXXX RFC XXXX
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Accept| header field is used in the WebSocket The |Sec-WebSocket-Accept| header field is used in the WebSocket
opening handshake. It is sent from the server to the client to opening handshake. It is sent from the server to the client to
confirm that the server is willing to initiate the connection. confirm that the server is willing to initiate the WebSocket
connection.
The |Sec-WebSocket-Accept| header MUST NOT appear more than once in
an HTTP response.
11.3.4. Sec-WebSocket-Protocol 11.3.4. Sec-WebSocket-Protocol
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Protocol Sec-WebSocket-Protocol
Applicable protocol Applicable protocol
skipping to change at page 61, line 23 skipping to change at page 64, line 34
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Protocol| header field is used in the WebSocket The |Sec-WebSocket-Protocol| header field is used in the WebSocket
opening handshake. It is sent from the client to the server and back opening handshake. It is sent from the client to the server and back
from the server to the client to confirm the subprotocol of the from the server to the client to confirm the subprotocol of the
connection. This enables scripts to both select a subprotocol and be connection. This enables scripts to both select a subprotocol and be
sure that the server agreed to serve that subprotocol. sure that the server agreed to serve that subprotocol.
The |Sec-WebSocket-Protocol| header field MAY appear multiple times
in an HTTP request (which is logically the same as a single |Sec-
WebSocket-Protocol| header field that contains all values. However
the |Sec-WebSocket-Protocol| header field MUST NOT appear more than
once in an HTTP response.
11.3.5. Sec-WebSocket-Version 11.3.5. Sec-WebSocket-Version
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry [RFC3864]. Permanent Message Header Field Registry [RFC3864].
Header field name Header field name
Sec-WebSocket-Version Sec-WebSocket-Version
Applicable protocol Applicable protocol
http http
skipping to change at page 62, line 12 skipping to change at page 65, line 32
cannot interpret that data in a safe manner. The |Sec-WebSocket- cannot interpret that data in a safe manner. The |Sec-WebSocket-
Version| header field is also sent from the server to the client on Version| header field is also sent from the server to the client on
WebSocket handshake error, when the version received from the client WebSocket handshake error, when the version received from the client
does not match a version understood by the server. In such a case does not match a version understood by the server. In such a case
the header field includes the protocol version(s) supported by the the header field includes the protocol version(s) supported by the
server. server.
Note that there is no expectation that higher version numbers are Note that there is no expectation that higher version numbers are
necessarily backward compatible with lower version numbers. necessarily backward compatible with lower version numbers.
The |Sec-WebSocket-Version| header field MAY appear multiple times in
an HTTP response (which is logically the same as a single |Sec-
WebSocket-Protocol| header field that contains all values. However
the |Sec-WebSocket-Protocol| header field MUST NOT appear more than
once in an HTTP request.
11.4. WebSocket Extension Name Registry 11.4. WebSocket Extension Name Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Extension names to be used with the WebSocket protocol in WebSocket Extension names to be used with the WebSocket protocol in
accordance with the principles set out in RFC 5226 [RFC5226]. accordance with the 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:
Extension Identifier Extension Identifier
skipping to change at page 64, line 46 skipping to change at page 68, line 46
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:
Status Code Status Code
The Status Code which denotes a reson for a WebSocket connection The Status Code which denotes a reason for a WebSocket connection
closure as per Section 7.4 of this document. The status code is closure as per Section 7.4 of this document. The status code is
an integer number between 1000 and 4999 (inclusive). an integer number between 1000 and 4999 (inclusive).
Meaning Meaning
The meaning of the status code. Each status code has to have a The meaning of the status code. Each status code has to have a
unique meaning. unique meaning.
Contact Contact
A contact for the entity reserving the status code. A contact for the entity reserving the status code.
skipping to change at page 66, line 21 skipping to change at page 70, line 21
| 1002 | Protocol error | hybi@ietf.org | RFC XXXX | | 1002 | Protocol error | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1003 | Unsupported Data| hybi@ietf.org | RFC XXXX | | 1003 | Unsupported Data| hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1004 | ---Reserved---- | hybi@ietf.org | RFC XXXX | | 1004 | ---Reserved---- | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1005 | No Status Rcvd | hybi@ietf.org | RFC XXXX | | 1005 | No Status Rcvd | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1006 | Abnormal Closure| hybi@ietf.org | RFC XXXX | | 1006 | Abnormal Closure| hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1007 | Invalid UTF-8 | hybi@ietf.org | RFC XXXX | | 1007 | Invalid frame | hybi@ietf.org | RFC XXXX |
| | payload data | | |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1008 | Policy Violation| hybi@ietf.org | RFC XXXX | | 1008 | Policy Violation| hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1009 | Message Too Big | hybi@ietf.org | RFC XXXX | | 1009 | Message Too Big | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1010 | Mandatory Ext. | hybi@ietf.org | RFC XXXX | | 1010 | Mandatory Ext. | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
11.8. WebSocket Opcode Registry 11.8. WebSocket Opcode Registry
skipping to change at page 69, line 39 skipping to change at page 73, line 39
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. Note that people listed Raymor, Jan Koehler, Joonas Lehtolahti, Sylvain Hellegouarch, Stephen
above didn't necessarily endorsed the end result of this work. Farrell, Pete Resnick. Note that people listed above didn't
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 71, line 49 skipping to change at page 75, line 49
April 2011. April 2011.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[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
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 Saldhana, A. and T. Roessler, "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 to Yourself for Fun and Profit", 2010, <http://
www.adambarth.com/papers/2011/
huang-chen-barth-rescorla-jackson.pdf>.
Authors' Addresses Authors' Addresses
Ian Fette Ian Fette
Google, Inc. Google, Inc.
Email: ifette+ietf@google.com Email: ifette+ietf@google.com
URI: http://www.ianfette.com/ URI: http://www.ianfette.com/
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
 End of changes. 65 change blocks. 
194 lines changed or deleted 320 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/