draft-ietf-hybi-thewebsocketprotocol-12.txt   draft-ietf-hybi-thewebsocketprotocol-13.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: February 25, 2012 Isode Ltd Expires: March 3, 2012 Isode Ltd
August 24, 2011 August 31, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-12 draft-ietf-hybi-thewebsocketprotocol-13
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 February 25, 2012. This Internet-Draft will expire on March 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 6 1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 7
1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 9 1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 9
1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 9 1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 10
1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 10 1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 11
1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 11 1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 12
1.8. Establishing a Connection . . . . . . . . . . . . . . . . 11 1.8. Establishing a Connection . . . . . . . . . . . . . . . . 12
1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 11 1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 12
2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 13 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 14
3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 15 3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 16 4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Client Requirements . . . . . . . . . . . . . . . . . . . 16 4.1. Client Requirements . . . . . . . . . . . . . . . . . . . 17
4.2. Server-side Requirements . . . . . . . . . . . . . . . . . 21 4.2. Server-side Requirements . . . . . . . . . . . . . . . . . 22
4.2.1. Reading the Client's Opening Handshake . . . . . . . . 21 4.2.1. Reading the Client's Opening Handshake . . . . . . . . 23
4.2.2. Sending the Server's Opening Handshake . . . . . . . . 22 4.2.2. Sending the Server's Opening Handshake . . . . . . . . 24
4.3. Collected ABNF for new header fields used in handshake . . 25 4.3. Collected ABNF for new header fields used in handshake . . 27
5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 27 5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 29
5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 31 5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 33
5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32 5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 34
5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 33 5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 36
5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 34 5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 36
5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 35 5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 38
5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 36 5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 39
6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 38 6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 40
6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 38 6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 40
6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 38 6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 40
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 40 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 42
7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 42
7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 40 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 42
7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 40 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 42
7.1.3. The WebSocket Closing Handshake is Started . . . . . . 40 7.1.3. The WebSocket Closing Handshake is Started . . . . . . 42
7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 41 7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 43
7.1.5. The WebSocket Connection Close Code . . . . . . . . . 41 7.1.5. The WebSocket Connection Close Code . . . . . . . . . 43
7.1.6. The WebSocket Connection Close Reason . . . . . . . . 41 7.1.6. The WebSocket Connection Close Reason . . . . . . . . 43
7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 42 7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 44
7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 42 7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 42 7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 44
7.2.2. Server-initiated closure . . . . . . . . . . . . . . . 43 7.2.2. Server-Initiated Closure . . . . . . . . . . . . . . . 45
7.3. Normal Closure of Connections . . . . . . . . . . . . . . 43 7.2.3. Recovering From Abnormal Closure . . . . . . . . . . . 45
7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 43 7.3. Normal Closure of Connections . . . . . . . . . . . . . . 45
7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 43 7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 45
7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 44 7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 46
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 46 7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 47
8.1. Handling Errors in UTF-8 Encoded Data . . . . . . . . . . 46 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 49
9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.1. Handling Errors in UTF-8 Encoded Data . . . . . . . . . . 49
9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 47 9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 48 9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 50
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 51
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 52
11.1. Registration of new URI Schemes . . . . . . . . . . . . . 52 10.1. Non-Browser Clients . . . . . . . . . . . . . . . . . . . 52
11.1.1. Registration of "ws:" Scheme . . . . . . . . . . . . . 52 10.2. Origin Considerations . . . . . . . . . . . . . . . . . . 52
11.1.2. Registration of "wss:" Scheme . . . . . . . . . . . . 53 10.3. Attacks On Infrastructure (Masking) . . . . . . . . . . . 53
11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 54 10.4. Implementation-Specific Limits . . . . . . . . . . . . . . 54
11.3. Registration of new HTTP Header Fields . . . . . . . . . . 54 10.5. WebSocket client authentication . . . . . . . . . . . . . 54
11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 54 10.6. Connection confidentiality and integrity . . . . . . . . . 55
11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 55 10.7. Handling of invalid data . . . . . . . . . . . . . . . . . 55
11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 56 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 56 11.1. Registration of new URI Schemes . . . . . . . . . . . . . 56
11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 57 11.1.1. Registration of "ws" Scheme . . . . . . . . . . . . . 56
11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 58 11.1.2. Registration of "wss" Scheme . . . . . . . . . . . . . 57
11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 59 11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 58
11.6. WebSocket Version Number Registry . . . . . . . . . . . . 59 11.3. Registration of new HTTP Header Fields . . . . . . . . . . 58
11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 60 11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 58
11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 62 11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 59
11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 63 11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 60
12. Using the WebSocket protocol from Other Specifications . . . . 64 11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 60
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 61
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 62
14.1. Normative References . . . . . . . . . . . . . . . . . . . 66 11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 62
14.2. Informative References . . . . . . . . . . . . . . . . . . 67 11.6. WebSocket Version Number Registry . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 64
11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 66
11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 67
12. Using the WebSocket protocol from Other Specifications . . . . 68
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
14.1. Normative References . . . . . . . . . . . . . . . . . . . 70
14.2. Informative References . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
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 12 skipping to change at page 6, line 12
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
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 8 Sec-WebSocket-Version: 13
The handshake from the server looks as follows: The handshake from the server looks as follows:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat Sec-WebSocket-Protocol: chat
The leading line from the client follows the Request-Line format. The leading line from the client follows the Request-Line format.
skipping to change at page 5, line 39 skipping to change at page 6, line 39
as cookies [RFC6265]. The format and parsing of headers is as as cookies [RFC6265]. The format and parsing of headers is as
defined in [RFC2616]. defined in [RFC2616].
Once the client and server have both sent their handshakes, and if Once the client and server have both sent their handshakes, and if
the handshake was successful, then the data transfer part starts. the handshake was successful, then the data transfer part starts.
This is a two-way communication channel where each side can, This is a two-way communication channel where each side can,
independently from the other, send data at will. independently from the other, send data at will.
Clients and servers, after a successful handshake, transfer data back Clients and servers, after a successful handshake, transfer data back
and forth in conceptual units referred to in this specification as and forth in conceptual units referred to in this specification as
"messages". A message is a complete unit of data at an application "messages". On the wire a message is composed of one or more frames.
level, with the expectation that many or most applications The WebSocket message does not necessarily correspond to a particular
implementing this protocol (such as web user agents) provide APIs in network layer framing, as a fragmented message may be coalesced or
terms of sending and receiving messages. The WebSocket message does split by an intermediary.
not necessarily correspond to a particular network layer framing, as
a fragmented message may be coalesced, or vice versa, e.g. by an
intermediary.
Data is sent on the wire in the form of frames that have an A frame has an associated type. Each frame belonging to the same
associated type. A message is composed of one or more frames, all of message contain the same type of data. Broadly speaking, there are
which contain the same type of data. Broadly speaking, there are
types for textual data, which is interpreted as UTF-8 [RFC3629] text, types for textual data, which is interpreted as UTF-8 [RFC3629] text,
binary data (whose interpretation is left up to the application), and binary data (whose interpretation is left up to the application), and
control frames, which are not intended to carry data for the control frames, which are not intended to carry data for the
application, but instead for protocol-level signaling, such as to application, but instead for protocol-level signaling, such as to
signal that the connection should be closed. This version of the signal that the connection should be closed. This version of the
protocol defines six frame types and leaves ten reserved for future protocol defines six frame types and leaves ten reserved for future
use. use.
The WebSocket protocol uses this framing so that specifications that
use the WebSocket protocol can expose such connections using an
event-based mechanism instead of requiring users of those
specifications to implement buffering and piecing together of
messages manually.
1.3. Opening Handshake 1.3. Opening Handshake
_This section is non-normative._ _This section is non-normative._
The opening handshake is intended to be compatible with HTTP-based The opening handshake is intended to be compatible with HTTP-based
server-side software and intermediaries, so that a single port can be server-side software and intermediaries, so that a single port can be
used by both HTTP clients talking to that server and WebSocket used by both HTTP clients talking to that server and WebSocket
clients talking to that server. To this end, the WebSocket client's clients talking to that server. To this end, the WebSocket client's
handshake is an HTTP Upgrade request: handshake is an HTTP Upgrade request:
GET /chat HTTP/1.1 GET /chat HTTP/1.1
Host: server.example.com Host: server.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 8 Sec-WebSocket-Version: 13
In compliance with [RFC2616], header fields in the handshake may be In compliance with [RFC2616], header fields in the handshake may be
sent by the client in any order, so the order in which different sent by the client in any order, so the order in which different
header fields are received is not significant. header fields are received is not significant.
The "Request-URI" of the GET method [RFC2616] is used to identify the The "Request-URI" of the GET method [RFC2616] is used to identify the
endpoint of the WebSocket connection, both to allow multiple domains endpoint of the WebSocket connection, both to allow multiple domains
to be served from one IP address and to allow multiple WebSocket to be served from one IP address and to allow multiple WebSocket
endpoints to be served by a single server. endpoints to be served by a single server.
The client includes the hostname in the Host header field of its The client includes the hostname in the Host header field of its
handshake as per [RFC2616], so that both the client and the server handshake as per [RFC2616], so that both the client and the server
can verify that they agree on which host is in use. can verify that they agree on which host is in use.
Additional header fields are used to select options in the WebSocket Additional header fields are used to select options in the WebSocket
protocol. Options available in this version are the subprotocol protocol. Typical options available in this version are the
selector, |Sec-WebSocket-Protocol|. The |Sec-WebSocket-Protocol| subprotocol selector (|Sec-WebSocket-Protocol|), list of extensions
request-header field can be used to indicate what subprotocols support by the client (|Sec-WebSocket-Extensions|), |Origin| header
(application-level protocols layered over the WebSocket protocol) are field, etc. The |Sec-WebSocket-Protocol| request-header field can be
acceptable to the client. The server selects one of the acceptable used to indicate what subprotocols (application-level protocols
protocols and echoes that value in its handshake to indicate that it layered over the WebSocket protocol) are acceptable to the client.
has selected that protocol. The server selects one or none of the acceptable protocols and echoes
that value in its handshake to indicate that it has selected that
protocol.
Sec-WebSocket-Protocol: chat Sec-WebSocket-Protocol: chat
The |Origin| header field [I-D.ietf-websec-origin] is used to protect The |Origin| header field [I-D.ietf-websec-origin] is used to protect
against unauthorized cross-origin use of a WebSocket server by against unauthorized cross-origin use of a WebSocket server by
scripts using the |WebSocket| API in a Web browser. The server is scripts using the |WebSocket| API in a Web browser. The server is
informed of the script origin generating the WebSocket connection informed of the script origin generating the WebSocket connection
request. If the server does not wish to accept connections from this request. If the server does not wish to accept connections from this
origin, it can choose to reject the connection by sending an origin, it can choose to reject the connection by sending an
appropriate HTTP error code. This header field is sent by browser appropriate HTTP error code. This header field is sent by browser
clients, for non-browser clients this header field may be sent if it clients, for non-browser clients this header field may be sent if it
skipping to change at page 8, line 29 skipping to change at page 9, line 23
the server is willing to accept the connection. If present, this the server is willing to accept the connection. If present, this
header field must include a hash of the client's nonce sent in |Sec- header field must include a hash of the client's nonce sent in |Sec-
WebSocket-Key| along with a predefined GUID. Any other value must WebSocket-Key| along with a predefined GUID. Any other value must
not be interpreted as an acceptance of the connection by the server. not be interpreted as an acceptance of the connection by the server.
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
These fields are checked by the Web browser when it is acting as a These fields are checked by the |WebSocket| client for scripted
|WebSocket| client for scripted pages. If the |Sec-WebSocket-Accept| pages. If the |Sec-WebSocket-Accept| value does not match the
value does not match the expected value, or if the header field is expected value, or if the header field is missing, or if the HTTP
missing, or if the HTTP status code is not 101, the connection will status code is not 101, the connection will not be established and
not be established and WebSocket frames will not be sent. WebSocket frames will not be sent.
Option fields can also be included. In this version of the protocol, Option fields can also be included. In this version of the protocol,
the main option field is |Sec-WebSocket-Protocol|, which indicates the main option field is |Sec-WebSocket-Protocol|, which indicates
the subprotocol that the server has selected. Web browsers verify the subprotocol that the server has selected. WebSocket clients
that the server included one of the values as was specified in the verify that the server included one of the values as was specified in
WebSocket client's handshake. A server that speaks multiple the WebSocket client's handshake. A server that speaks multiple
subprotocols has to make sure it selects one based on the client's subprotocols has to make sure it selects one based on the client's
handshake and specifies it in its handshake. handshake and specifies it in its handshake.
Sec-WebSocket-Protocol: chat Sec-WebSocket-Protocol: chat
The server can also set cookie-related option fields to _set_ The server can also set cookie-related option fields to _set_
cookies, as described in [RFC6265]. cookies, as described in [RFC6265].
1.4. Closing Handshake 1.4. Closing Handshake
skipping to change at page 10, line 21 skipping to change at page 11, line 12
o layers a framing mechanism on top of TCP to get back to the IP o layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length limits packet mechanism that TCP is built on, but without length limits
o includes an additional closing handshake in-band that is designed o includes an additional closing handshake in-band that is designed
to work in the presence of proxies and other intermediaries to work in the presence of proxies and other intermediaries
Other than that, WebSocket adds nothing. Basically it is intended to Other than that, WebSocket adds nothing. Basically it is intended to
be as close to just exposing raw TCP to script as possible given the be as close to just exposing raw TCP to script as possible given the
constraints of the Web. It's also designed in such a way that its constraints of the Web. It's also designed in such a way that its
servers can share a port with HTTP servers, by having its handshake servers can share a port with HTTP servers, by having its handshake
be a valid HTTP Upgrade request mechanism also. be a valid HTTP Upgrade request mechanism also. One could
conceptually use other protocols to establish client-server
messaging, but the intent of WebSockets was to provide a relatively
simple protocol that can coexist with HTTP and deployed HTTP
infrastructure (such as proxies) that is as close to TCP as is safe
for use with such infrastructure given security considerations, with
targeted additions to simplify usage and make simple things simple
(such as the addition of message semantics).
The protocol is intended to be extensible; future versions will The protocol is intended to be extensible; future versions will
likely introduce additional concepts such as multiplexing. likely introduce additional concepts such as multiplexing.
1.6. Security Model 1.6. Security Model
_This section is non-normative._ _This section is non-normative._
The WebSocket protocol uses the origin model used by Web browsers to The WebSocket protocol uses the origin model used by Web browsers to
restrict which Web pages can contact a WebSocket server when the restrict which Web pages can contact a WebSocket server when the
skipping to change at page 13, line 11 skipping to change at page 14, line 11
versioning can be implemented by reusing the same subprotocol string versioning can be implemented by reusing the same subprotocol string
but carefully designing the actual subprotocol to support this kind but carefully designing the actual subprotocol to support this kind
of extensibility. of extensibility.
2. Conformance Requirements 2. Conformance Requirements
All diagrams, examples, and notes in this specification are non- All diagrams, examples, and notes in this specification are non-
normative, as are all sections explicitly marked non-normative. normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119. [RFC2119] document are to be interpreted as described in RFC2119. [RFC2119]
Requirements phrased in the imperative as part of algorithms (such as Requirements phrased in the imperative as part of algorithms (such as
"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
skipping to change at page 18, line 19 skipping to change at page 19, line 19
WebSocket connections, if available, or failing that, to prefer WebSocket connections, if available, or failing that, to prefer
the proxy configured for HTTPS connections over the proxy the proxy configured for HTTPS connections over the proxy
configured for HTTP connections. configured for HTTP connections.
For the purpose of proxy autoconfiguration scripts, the URI to For the purpose of proxy autoconfiguration scripts, the URI to
pass the function MUST be constructed from /host/, /port/, pass the function MUST be constructed from /host/, /port/,
/resource name/, and the /secure/ flag using the definition of a /resource name/, and the /secure/ flag using the definition of a
WebSocket URI as given in Section 3. WebSocket URI as given in Section 3.
NOTE: The WebSocket protocol can be identified in proxy NOTE: The WebSocket protocol can be identified in proxy
autoconfiguration scripts from the scheme ("ws:" for unencrypted autoconfiguration scripts from the scheme ("ws" for unencrypted
connections and "wss:" for encrypted connections). connections and "wss" for encrypted connections).
4. If the connection could not be opened, either because a direct 4. If the connection could not be opened, either because a direct
connection failed or because any proxy used returned an error, connection failed or because any proxy used returned an error,
then the client MUST _Fail the WebSocket Connection_ and abort then the client MUST _Fail the WebSocket Connection_ and abort
the connection attempt. the connection attempt.
5. If /secure/ is true, the client MUST perform a TLS handshake over 5. If /secure/ is true, the client MUST perform a TLS handshake over
the connection after opening the connection and before sending the connection after opening the connection and before sending
the handshake data [RFC2818]. If this fails (e.g. the server's the handshake data [RFC2818]. If this fails (e.g. the server's
certificate could not be verified), then the client MUST _Fail certificate could not be verified), then the client MUST _Fail
skipping to change at page 19, line 46 skipping to change at page 20, line 46
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 is running on www.example.com attempting
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 8. WebSocket-Version". The value of this header field MUST be 13.
_Note: Although drafts -09, -10 and -11 were published, as they _Note: Although drafts -09, -10, -11 and -12 were published, as
were mostly comprised of editorial changes and clarifications they were mostly comprised of editorial changes and
and not changes to the wire protocol, values 9, 10 and 11 were clarifications and not changes to the wire protocol, values 9,
not used as valid values for Sec-WebSocket-Version. These 10, 11 and 12 were not used as valid values for Sec-WebSocket-
values were reserved in the IANA registry but were not and will Version. These values were reserved in the IANA registry but
not be used. If subsequent changes to the wire protocol are were not and will not be used._
necessary, values 9, 10 and 11 will be skipped to prevent
confusion with the draft 9/10/11 protocol._
10. The request MAY include a header field with the name "Sec- 10. The request MAY include a header field with the name "Sec-
WebSocket-Protocol". If present, this value indicates one or WebSocket-Protocol". If present, this value indicates one or
more comma separated subprotocol the client wishes to speak, more comma separated subprotocol the client wishes to speak,
ordered by preference. The elements that comprise this value ordered by preference. The elements that comprise this value
MUST be non-empty strings with characters in the range U+0021 to MUST be non-empty strings with characters in the range U+0021 to
U+007E not including separator characters as defined in U+007E not including separator characters as defined in
[RFC2616], and MUST all be unique strings. The ABNF for the [RFC2616], and MUST all be unique strings. The ABNF for the
value of this header field is 1#token, where the definitions of value of this header field is 1#token, where the definitions of
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]. cookies [RFC6265] and/or authentication related header fields
such as Authorization header field [RFC2616].
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 procedures. Otherwise, client handles the response per HTTP [RFC2616] procedures, in
proceed as follows. particular the client might perform authentication if it receives
401 status code, the server might redirect the client using a 3xx
status code (but clients are not required to follow them), etc.
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 contains a value that is not an ASCII "Connection" header field doesn't contains a token that is an
case-insensitive match for the value "Upgrade", the client MUST ASCII case-insensitive match for the value "Upgrade", the client
_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_
5. If the response includes a "Sec-WebSocket-Extensions" header 5. If the response includes a "Sec-WebSocket-Extensions" header
field, and this header field indicates the use of an extension field, and this header field indicates the use of an extension
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,
and this header field indicates the use of a subprotocol that was
not present in the client' handshake (the server has indicated a
subprotocol not requested by the client), the client MUST _Fail
the WebSocket Connection_. (The parsing of this header field to
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_.
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
skipping to change at page 22, line 9 skipping to change at page 23, line 20
4.2.1. Reading the Client's Opening Handshake 4.2.1. Reading the Client's Opening Handshake
When a client starts a WebSocket connection, it sends its part of the When a client starts a WebSocket connection, it sends its part of the
opening handshake. The server must parse at least part of this opening handshake. The server must parse at least part of this
handshake in order to obtain the necessary information to generate handshake in order to obtain the necessary information to generate
the server part of the handshake. the server part of the handshake.
The client's opening handshake consists of the following parts. If The client's opening handshake consists of the following parts. If
the server, while reading the handshake, finds that the client did the server, while reading the handshake, finds that the client did
not send a handshake that matches the description below, including not send a handshake that matches the description below (note that as
but not limited to any violations of the grammar (ABNF) specified for per [RFC2616] the order of the header fields is not important),
the components of the handshake, the server MUST stop processing the including but not limited to any violations of the grammar (ABNF)
client's handshake, and return an HTTP response with an appropriate specified for the components of the handshake, the server MUST stop
error code (such as 400 Bad Request). processing the client's handshake, and return an HTTP response with
an appropriate error code (such as 400 Bad Request).
1. An HTTP/1.1 or higher GET request, including a "Request-URI" 1. An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/ [RFC2616] that should be interpreted as a /resource name/
Section 3 (or an absolute HTTP/HTTPS URI containing the /resource Section 3 (or an absolute HTTP/HTTPS URI containing the
name/). /resource name/).
2. A "Host" header field containing the server's authority. 2. A "Host" header field containing the server's authority.
3. A "Sec-WebSocket-Key" header field with a base64-encoded (see 3. An "Upgrade" header field containing the value "websocket",
Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in treated as an ASCII case-insensitive value.
length.
4. A "Sec-WebSocket-Version" header field, with a value of 8. 4. A "Connection" header field that includes the token "Upgrade",
treated as an ASCII case-insensitive value.
5. Optionally, a "Origin" header field. This header field is sent 5. A "Sec-WebSocket-Key" header field with a base64-encoded (see
by all browser clients. A connection attempt lacking this header Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in
field SHOULD NOT be interpreted as coming from a browser client. length.
6. Optionally, a "Sec-WebSocket-Protocol" header field, with a list 6. A "Sec-WebSocket-Version" header field, with a value of 8.
of values indicating which protocols the client would like to
speak, ordered by preference.
7. Optionally, a "Sec-WebSocket-Extensions" header field, with a 7. Optionally, a "Origin" header field. This header field is sent
list of values indicating which extensions the client would like by all browser clients. A connection attempt lacking this
to speak. The interpretation of this header field is discussed header field SHOULD NOT be interpreted as coming from a browser
in Section 9.1. client.
8. Optionally, other header fields, such as those used to send 8. Optionally, a "Sec-WebSocket-Protocol" header field, with a list
cookies to a server. Unknown header fields MUST be ignored. of values indicating which protocols the client would like to
speak, ordered by preference.
9. Optionally, a "Sec-WebSocket-Extensions" header field, with a
list of values indicating which extensions the client would like
to speak. The interpretation of this header field is discussed
in Section 9.1.
10. Optionally, other header fields, such as those used to send
cookies or request authentication to a server. Unknown header
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 server supports encryption, perform a TLS handshake over
the connection. If this fails (e.g. the client indicated a host the connection. If this fails (e.g. the client indicated a host
name in the extended client hello "server_name" extension that name in the extended client hello "server_name" extension that
the server does not host), then close the connection; otherwise, the server does not host), then close the connection; otherwise,
all further communication for the connection (including the all further communication for the connection (including the
server's handshake) MUST run through the encrypted tunnel. server's handshake) MUST run through the encrypted tunnel.
[RFC5246] [RFC5246]
2. Establish the following information: 2. If the server wishes to perform additional client authentication,
it might return 401 status code with the corresponding WWW-
Authenticate header field as described in [RFC2616].
3. The server MAY redirect the client using a 3xx status code
[RFC2616]. Note that this step can happen together with, before
or after the optional authentication step described above.
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
origin is serialized to ASCII and converted to lowercase. The origin is serialized to ASCII and converted to lowercase. The
server MAY use this information as part of a determination of server MAY use this information as part of a determination of
whether to accept the incoming connection. If the server does whether to accept the incoming connection. If the server does
not validate the origin, it will accept connections from not validate the origin, it will accept connections from
anywhere. If the server does not wish to accept this anywhere. If the server does not wish to accept this
connection, it MUST return an appropriate HTTP error code connection, it MUST return an appropriate HTTP error code
skipping to change at page 24, line 35 skipping to change at page 26, line 17
extensions the server is ready to use. If the server supports extensions the server is ready to use. If the server supports
multiple extensions, then the value MUST be derived from the multiple extensions, then the value MUST be derived from the
client's handshake, specifically by selecting one or more of client's handshake, specifically by selecting one or more of
the values from the "Sec-WebSocket-Extensions" field. The the values from the "Sec-WebSocket-Extensions" field. The
absence of such a field is equivalent to the null value. The absence of such a field is equivalent to the null value. The
empty string is not the same as the null value for these empty string is not the same as the null value for these
purposes. Extensions not listed by the client MUST NOT be purposes. Extensions not listed by the client MUST NOT be
listed. The method by which these values should be selected listed. The method by which these values should be selected
and interpreted is discussed in Section 9.1. and interpreted is discussed in Section 9.1.
3. If the server chooses to accept the incoming connection, it MUST 5. If the server chooses to accept the incoming connection, it MUST
reply with a valid HTTP response indicating the following. reply with a valid HTTP response indicating the following.
1. A Status-Line with a 101 response code as per RFC 2616 1. A Status-Line with a 101 response code as per RFC 2616
[RFC2616]. Such a response could look like "HTTP/1.1 101 [RFC2616]. Such a response could look like "HTTP/1.1 101
Switching Protocols" Switching Protocols"
2. An "Upgrade" header field with value "websocket" as per RFC 2. An "Upgrade" header field with value "websocket" as per RFC
2616 [RFC2616]. 2616 [RFC2616].
3. A "Connection" header field with value "Upgrade" 3. A "Connection" header field with value "Upgrade"
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 2 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
base64-value = *base64-data [ base64-padding ] base64-value = *base64-data [ base64-padding ]
base64-data = 4base64-character base64-data = 4base64-character
base64-padding = (2base64-character "==") | (3base64-character "=") base64-padding = (2base64-character "==") |
base64-character = ALPHA | DIGIT | "+" | "/" (3base64-character "=")
base64-character = ALPHA | DIGIT | "+" | "/"
NOTE: As an example, if the value of the "Sec-WebSocket-Key" NOTE: As an example, if the value of the "Sec-WebSocket-Key"
header field in the client's handshake were header field in the client's handshake were
"dGhlIHNhbXBsZSBub25jZQ==", the server would append the "dGhlIHNhbXBsZSBub25jZQ==", the server would append the
string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the
string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
C5AB0DC85B11". The server would then take the SHA-1 hash of C5AB0DC85B11". The server would then take the SHA-1 hash of
this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62
0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe
0xc4 0xea. This value is then base64-encoded, to give the 0xc4 0xea. This value is then base64-encoded, to give the
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 2 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 2 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 must all be listed in a single Sec-WebSocket-Extensions
header field. This header field MUST NOT be repeated. header field. This header field MUST NOT be repeated.
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 section of the document this section is using ABNF
syntax/rules from [RFC2616], including "implied WSP rule". syntax/rules from Section 2.1 of [RFC2616], including "implied *LWS
rule".
Note that the following ABNF conventions are used in this section:
Some names of the rules correspond to names of the corresponding
header fields. Such rules express values of the corresponding header
fields, for example the Sec-WebSocket-Key ABNF rule describes syntax
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 to the server; ABNF rules with the "-Server" suffix in the
name are only used in responses sent by the server to the client.
For example, the ABNF rule Sec-WebSocket-Protocol-Client describes
syntax of the Sec-WebSocket-Protocol header field value sent by the
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
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 = *base64-data [ base64-padding ]
base64-data = 4base64-character base64-data = 4base64-character
base64-padding = (2base64-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 | private-use-token extension = extension-token *( ";" extension-param )
registered-token = token extension-token = registered-token
private-use-token = "x-" token registered-token = token
extension-param = token [ "=" token ] extension-param = token [ "=" token ]
version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) NZDIGIT = "1" | "2" | "3" | "4" | "5" | "6" |
; 0-255 "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
Sec-WebSocket-Protocol-Server = token Sec-WebSocket-Protocol-Server = token
Sec-WebSocket-Version-Server = 1#version Sec-WebSocket-Version-Server = 1#version
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. 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.
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
payload length, and designated locations for extension and payload length, and designated locations for extension and
application data, which together define the _payload_ data. Certain application data, which together define the _payload_ data. Certain
bits and opcodes are reserved for future expansion of the protocol. bits and opcodes are reserved for future expansion of the protocol.
A data frame MAY be transmitted by either the client or the server at A data frame MAY be transmitted by either the client or the server at
any time after opening handshake completion and before that endpoint any time after opening handshake completion and before that endpoint
has sent a close frame (Section 5.5.1). has sent a close frame (Section 5.5.1).
skipping to change at page 30, line 9 skipping to change at page 32, line 9
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
; 1 bit, MUST be 0 unless negotiated otherwise ; 1 bit, MUST be 0 unless negotiated
; otherwise
frame-rsv2 = %x0 frame-rsv2 = %x0
; 1 bit, MUST be 0 unless negotiated otherwise ; 1 bit, MUST be 0 unless negotiated
; otherwise
frame-rsv3 = %x0 frame-rsv3 = %x0
; 1 bit, MUST be 0 unless negotiated otherwise ; 1 bit, MUST be 0 unless negotiated
; 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 ; reserved for further non-control frames / %x3-7
; reserved for further non-control frames
/ %x8 ; connection close / %x8 ; connection close
/ %x9 ; ping / %x9 ; ping
/ %xA ; pong / %xA ; pong
/ %xB-F ; reserved for further control frames / %xB-F ; reserved for further control frames
frame-masked = %x0 ; frame is not masked, no frame-masking-key frame-masked = %x0
/ %x1 ; frame is masked, frame-masking-key present ; frame is not masked, no frame-masking-key
/ %x1
; frame is masked, frame-masking-key present
frame-payload-length = %x00-7D frame-payload-length = %x00-7D
/ %x7E frame-payload-length-16 / %x7E frame-payload-length-16
/ %x7F frame-payload-length-63 / %x7F frame-payload-length-63
frame-payload-length-16 = %x0000-FFFF frame-payload-length-16 = %x0000-FFFF
frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
frame-masking-key = 4( %0x00-FF ) ; present only if frame-masked is 1 frame-masking-key = 4( %0x00-FF )
; present only if frame-masked is 1
frame-payload-data = (frame-masked-extension-data frame-payload-data = (frame-masked-extension-data
frame-masked-application-data) ; frame-masked 1 frame-masked-application-data)
/ (frame-unmasked-extension-data ; frame-masked 1
frame-unmasked-application-data) ; frame-masked 0 / (frame-unmasked-extension-data
frame-unmasked-application-data)
; frame-masked 0
frame-masked-extension-data = *( %x00-FF ) ; to be defined later frame-masked-extension-data = *( %x00-FF ) ; to be defined later
frame-masked-application-data = *( %x00-FF ) frame-masked-application-data = *( %x00-FF )
frame-unmasked-extension-data = *( %x00-FF ) ; to be defined later frame-unmasked-extension-data = *( %x00-FF ) ; to be defined later
frame-unmasked-application-data = *( %x00-FF ) frame-unmasked-application-data = *( %x00-FF )
5.3. Client-to-Server Masking 5.3. Client-to-Server Masking
The client MUST mask all frames sent to the server. A server MUST The client MUST mask all frames sent to the server. This is required
close the connection upon receiving a frame with the MASK bit set to for security reasons which are further discussed in Section 10.3. A
0. In this case, a server MAY send a close frame with a status code server MUST close the connection upon receiving a frame with the MASK
of 1002 (protocol error) as defined in Section 7.4.1. bit set to 0. In this case, a server MAY send a close frame with a
status code of 1002 (protocol error) as defined in Section 7.4.1.
A masked frame MUST have the field frame-masked set to 1, as defined A masked frame MUST have the field frame-masked set to 1, as defined
in Section 5.2. in Section 5.2.
The masking key is contained completely within the frame, as defined The masking key is contained completely within the frame, as defined
in Section 5.2 as frame-masking-key. It is used to mask the payload in Section 5.2 as frame-masking-key. It is used to mask the payload
data defined in the same section as frame-payload-data, which data defined in the same section as frame-payload-data, which
includes extension and application data. includes extension and application data.
The masking key is a 32-bit value chosen at random by the client. The masking key is a 32-bit value chosen at random by the client.
skipping to change at page 32, line 21 skipping to change at page 34, line 28
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.
Unless specified otherwise by an extension, frames have no semantic
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, but the intermediary understood all the
extensions negotiated and knows how to coalesce and/or split frames
in presence of these extensions. One implication of this is that in
absence of extensions senders and receivers must not depend on
presence of specific frame boundaries.
The following rules apply to fragmentation: The following rules apply to fragmentation:
o An unfragmented message consists of a single frame with the FIN o An unfragmented message consists of a single frame with the FIN
bit set and an opcode other than 0. bit set and an opcode other than 0.
o A fragmented message consists of a single frame with the FIN bit o A fragmented message consists of a single frame with the FIN bit
clear and an opcode other than 0, followed by zero or more frames clear and an opcode other than 0, followed by zero or more frames
with the FIN bit clear and the opcode set to 0, and terminated by with the FIN bit clear and the opcode set to 0, and terminated by
a single frame with the FIN bit set and an opcode of 0. A a single frame with the FIN bit set and an opcode of 0. A
fragmented message is conceptually equivalent to a single larger fragmented message is conceptually equivalent to a single larger
skipping to change at page 33, line 41 skipping to change at page 36, line 10
the same type, as set by the first fragment's opcode. Since the same type, as set by the first fragment's opcode. Since
Control frames cannot be fragmented, the type for all fragments in Control frames cannot be fragmented, the type for all fragments in
a message MUST be either text or binary, or one of the reserved a message MUST be either text or binary, or one of the reserved
opcodes. opcodes.
_Note: if control frames could not be interjected, the latency of a _Note: if control frames could not be interjected, the latency of a
ping, for example, would be very long if behind a large message. ping, for example, would be very long if behind a large message.
Hence, the requirement of handling control frames in the middle of a Hence, the requirement of handling control frames in the middle of a
fragmented message._ fragmented message._
_Implementation Note: in absence of any extension a receiver doesn't
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
application. But note that that assumption might not hold true for
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.
Control frames are used to communicate state about the WebSocket. Control frames are used to communicate state about the WebSocket.
Control frames can be interjected in the middle of a fragmented Control frames can be interjected in the middle of a fragmented
message. message.
skipping to change at page 36, line 4 skipping to change at page 38, line 29
0x3-0x7 are reserved for further non-control frames yet to be 0x3-0x7 are reserved for further non-control frames yet to be
defined. defined.
Data frames carry application-layer and/or extension-layer data. The Data frames carry application-layer and/or extension-layer data. The
opcode determines the interpretation of the data: opcode determines the interpretation of the data:
Text Text
The payload data is text data encoded as UTF-8. Note that a The payload data is text data encoded as UTF-8. Note that a
particular text frame might include a partial UTF-8 sequence, particular text frame might include a partial UTF-8 sequence,
however the whole message MUST contain valid 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.
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._ _This section is non-normative._
skipping to change at page 42, line 30 skipping to change at page 44, line 30
If _The WebSocket Connection is Established_ prior to the point where If _The WebSocket Connection is Established_ prior to the point where
the endpoint is required to _Fail the WebSocket Connection_, the the endpoint is required to _Fail the WebSocket Connection_, the
endpoint SHOULD send a Close frame with an appropriate status code endpoint SHOULD send a Close frame with an appropriate status code
Section 7.4 before proceeding to _Close the WebSocket Connection_. Section 7.4 before proceeding to _Close the WebSocket Connection_.
An endpoint MAY omit sending a Close frame if it believes the other An endpoint MAY omit sending a Close frame if it believes the other
side is unlikely to be able to receive and process the close frame, side is unlikely to be able to receive and process the close frame,
due to the nature of the error that led to the WebSocket connection due to the nature of the error that led to the WebSocket connection
being failed in the first place. An endpoint MUST NOT continue to being failed in the first place. An endpoint MUST NOT continue to
attempt to process data (including a responding Close frame) from the attempt to process data (including a responding Close frame) from the
remote endpoint after being instruted to _Fail the WebSocket remote endpoint after being instructed to _Fail the WebSocket
Connection_. Connection_.
Except as indicated above or as specified by the application layer Except as indicated above or as specified by the application layer
(e.g. a script using the WebSocket API), clients SHOULD NOT close the (e.g. a script using the WebSocket API), clients SHOULD NOT close the
connection. connection.
7.2. Abnormal Closures 7.2. Abnormal Closures
7.2.1. Client-Initiated Closure 7.2.1. Client-Initiated Closure
skipping to change at page 43, line 5 skipping to change at page 45, line 5
client to _Fail the WebSocket Connection_. To do so, the client MUST client to _Fail the WebSocket Connection_. To do so, the client MUST
_Fail the WebSocket Connection_ as defined in Section 7.1.7. _Fail the WebSocket Connection_ as defined in Section 7.1.7.
If at any point the underlying transport layer connection is If at any point the underlying transport layer connection is
unexpectedly lost, the client MUST _Fail the WebSocket Connection_. unexpectedly lost, the client MUST _Fail the WebSocket Connection_.
Except as indicated above or as specified by the application layer Except as indicated above or as specified by the application layer
(e.g. a script using the WebSocket API), clients SHOULD NOT close the (e.g. a script using the WebSocket API), clients SHOULD NOT close the
connection. connection.
7.2.2. Server-initiated closure 7.2.2. Server-Initiated Closure
Certain algorithms require or recommend that the server _Abort the Certain algorithms require or recommend that the server _Abort the
WebSocket Connection_ during the opening handshake. To do so, the WebSocket Connection_ during the opening handshake. To do so, the
server MUST simply _Close the WebSocket Connection_ (Section 7.1.1). server MUST simply _Close the WebSocket Connection_ (Section 7.1.1).
7.2.3. Recovering From Abnormal Closure
Abnormal closures may be caused by any number of reasons. Such
closures could be the result of a transient error, in which case
reconnecting may lead to a good connection and a resumption of normal
operations. Such closures may also be the result of a nontransient
problem, in which case if each deployed client experiences an
abnormal closure and immediately and persistently tries to reconnect,
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
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.
To prevent this, clients SHOULD use some form of backoff when trying
to reconnect after abnormal closures as described in this section.
The first reconnect attempt SHOULD be delayed by a random amount of
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
seconds is a reasonable initial delay though clients MAY choose a
different interval from which to select a delay length based on
implementation experience and particular application.
Should the first reconnect attempt fail, subsequent reconnect
attempts SHOULD be delayed by increasingly longer amounts of time,
using a method such as truncated binary exponential backoff.
7.3. Normal Closure of Connections 7.3. Normal Closure of Connections
Servers MAY close the WebSocket connection whenever desired. Clients Servers MAY close the WebSocket connection whenever desired. Clients
SHOULD NOT close the WebSocket connection arbitrarily. In either SHOULD NOT close the WebSocket connection arbitrarily. In either
case, an endpoint initiates a closure by following the procedures to case, an endpoint initiates a closure by following the procedures to
_Start the WebSocket Closing Handshake_ (Section 7.1.2). _Start the WebSocket Closing Handshake_ (Section 7.1.2).
7.4. Status Codes 7.4. Status Codes
When closing an established connection (e.g. when sending a Close When closing an established connection (e.g. when sending a Close
skipping to change at page 44, line 14 skipping to change at page 46, line 37
1003 1003
1003 indicates that an endpoint is terminating the connection 1003 indicates that an endpoint is terminating the connection
because it has received a type of data it cannot accept (e.g. an because it has received a type of data it cannot accept (e.g. an
endpoint that understands only text data MAY send this if it endpoint that understands only text data MAY send this if it
receives a binary message). receives a binary message).
1004 1004
1004 indicates that an endpoint is terminating the connection Reserved. The specific meaning might be defined in the future.
because it has received a frame that is too large.
1005 1005
1005 is a reserved value and MUST NOT be set as a status code in a 1005 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 no status applications expecting a status code to indicate that no status
code was actually present. code was actually present.
1006 1006
skipping to change at page 44, line 38 skipping to change at page 47, line 12
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 that was supposed to be UTF-8 (such
as in a text frame) that was in fact not valid UTF-8 [RFC3629]. as in a text frame) that was in fact not valid UTF-8 [RFC3629].
1008
1008 indicates that an endpoint is terminating the connection
because it has received a message that violates its policy. This
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
is a need to hide specific details about the policy.
1009
1009 indicates that an endpoint is terminating the connection
because it has received a message which is too big for it to
process.
1010
1010 indicates that an endpoint (client) is terminating the
connection because it has expected the server to negotiate one or
more extension, but the server didn't return them in the response
message of the WebSocket handshake. The list of extensions which
are needed SHOULD appear in the /reason/ part of the Close frame.
Note that this status code is not used by the server, because it
can fail the WebSocket handshake instead.
7.4.2. Reserved Status Code Ranges 7.4.2. Reserved Status Code Ranges
0-999 0-999
Status codes in the range 0-999 are not used. Status codes in the range 0-999 are not used.
1000-2999 1000-2999
Status codes in the range 1000-2999 are reserved for definition by Status codes in the range 1000-2999 are reserved for definition by
this protocol, its future revisions, and extensions specified in a this protocol, its future revisions, and extensions specified in a
skipping to change at page 46, line 11 skipping to change at page 49, line 11
and thus can't be registered. Such codes can be used by prior and thus can't be registered. Such codes can be used by prior
agreements between WebSocket applications. The interpretation of agreements between WebSocket applications. The interpretation of
these codes is undefined by this protocol. these codes is undefined by this protocol.
8. Error Handling 8. Error Handling
8.1. Handling Errors in UTF-8 Encoded Data 8.1. Handling Errors in UTF-8 Encoded Data
When an endpoint is to interpret a byte stream as UTF-8 but finds When an endpoint is to interpret a byte stream as UTF-8 but finds
that the byte stream is not in fact a valid UTF-8 stream, that that the byte stream is not in fact a valid UTF-8 stream, that
endpoint MUST _Fail the WebSocket Connection_. endpoint MUST _Fail the WebSocket Connection_. This rule applies
both during the opening handshake and during subsequent data
exchange.
9. Extensions 9. Extensions
WebSocket clients MAY request extensions to this specification, and WebSocket clients MAY request extensions to this specification, and
WebSocket servers MAY accept some or all extensions requested by the WebSocket servers MAY accept some or all extensions requested by the
client. A server MUST NOT respond with any extension not requested client. A server MUST NOT respond with any extension not requested
by the client. If extension parameters are included in negotiations by the client. If extension parameters are included in negotiations
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 section of the document this section is using ABNF syntax/rules from
[RFC2616], including "implied WSP 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 | private-use-token extension-token = registered-token
registered-token = token registered-token = token
private-use-token = "x-" token
extension-param = token [ "=" token ] extension-param = token [ "=" token ]
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
Sec-WebSocket-Extensions: foo, bar; baz=2 Sec-WebSocket-Extensions: foo, bar; baz=2
Any extension-token used MUST either be a registered token (see Any extension-token used MUST be a registered token (see
Section 11.4), or have a prefix of "x-" to indicate a private-use Section 11.4). The parameters supplied with any given extension MUST
token. The parameters supplied with any given extension MUST be be defined for that extension. Note that the client is only offering
defined for that extension. Note that the client is only offering to to use any advertised extensions, and MUST NOT use them unless the
use any advertised extensions, and MUST NOT use them unless the
server indicates that it wishes to use the extension. server indicates that it wishes to use the extension.
Note that the order of extensions is significant. Any interactions Note that the order of extensions is significant. Any interactions
between multiple extensions MAY be defined in the documents defining between multiple extensions MAY be defined in the documents defining
the extensions. In the absence of such definition, the the extensions. In the absence of such definition, the
interpretation is that the header fields listed by the client in its interpretation is that the header fields listed by the client in its
request represent a preference of the header fields it wishes to use, request represent a preference of the header fields it wishes to use,
with the first options listed being most preferable. The extensions with the first options listed being most preferable. The extensions
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 thay may "stack".
Non-normative examples of acceptable extension header fields: Non-normative examples of acceptable extension header fields (note
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, deflate-stream Sec-WebSocket-Extensions: mux; max-channels=4; flow-control,
Sec-WebSocket-Extensions: x-private-extension deflate-stream
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-
WebSocket-Extensions| header field containing one or more extensions WebSocket-Extensions| header field containing one or more extensions
which were requested by the client. The interpretation of any which were requested by the client. The interpretation of any
extension parameters, and what constitutes a valid response by a extension parameters, and what constitutes a valid response by a
server to a requested set of parameters by a client, will be defined server to a requested set of parameters by a client, will be defined
by each such extension. by each such extension.
9.2. Known Extensions 9.2. Known Extensions
Extensions provide a mechanism for implementations to opt-in to Extensions provide a mechanism for implementations to opt-in to
additional protocol features. This document doesn't define any additional protocol features. This document doesn't define any
extension but implementations MAY use extensions defined separately. extension but implementations MAY use extensions defined separately.
10. Security Considerations 10. Security Considerations
This section describes some security considerations applicable to the
WebSocket protocol. Specific security considerations are described
in subsections of this section.
10.1. Non-Browser Clients
Many threats anticipated by the WebSocket protocol protect from
malicious JavaScript running inside a trusted application such as a
web browser, for example checking of the "Origin" header field (see
below). See Section 1.6 for additional details. Such assumptions
don't hold true in a 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
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, and should only respond with the corresponding "Sec-
WebSocket-Accept" if it is an accepted origin. WebSocket-Accept" if it is an accepted origin.
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.
This document doesn't prescribe any particular way that servers can 10.3. Attacks On Infrastructure (Masking)
In addition to endpoints being the target of attacks via WebSockets,
other parts of web infrastructure, such as proxies, may be the
subject of an attack.
As this protocol was being developed, an experiment was conducted to
demonstrate a class of attacks on proxies that led to the poisoning
of caching proxies deployed in the wild. The general form of the
attack was to establish a connection to a server under the
"attacker's" control, perform an UPGRADE on the HTTP connection
similar to what the WebSocket protocol does to establish a
connection, and to subsequently send data over that UPGRADEd
connection that looked like a GET request for a specific known
resource (which in an attack would likely be something like a widely
deployed script for tracking hits, or a resource on an ad-serving
network). The remote server would respond with something that looked
like a response to the fake GET request, and this response would be
cached by a nonzero percentage of deployed intermediaries, thus
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,
the attacker could potentially poison the cache for that user and
other users behind the same cache and run malicious script on other
origins, compromising the web security model.
To avoid such attacks on deployed intermediaries, the working group
decided to adopt a solution that would provably protect against such
attacks. There were many proposed solutions that people argued
"should" protect against the above attacks, such as adding in more
random data and null bytes to the handshake, starting each frame with
a byte that has the first (highest order) bit set such that the data
appears to be non-ASCII, and so forth, but in the end none of these
solutions were provably secure. The deployed intermediaries were
already not conforming to existing specifications, and given that we
can't possibly enumerate all of the ways in which such
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
frame. If the same key is used, or a decipherable pattern exists for
how the next key is chosen, the attacker can send a message that,
when masked, could 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
client has begun, the payload (application supplied data) of that
frame must not be capable of being modified by the application.
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
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
when masked. (This is essentially the same problem described in the
previous paragraph with using a known or predictable masking key.)
If additional data is to be sent or data to be sent is somehow
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
begins, the contents must not be modifiable by the remote script
(application).
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
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
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
data in both directions (the data from the server to the client is
not masked).
10.4. Implementation-Specific Limits
Implementations MAY impose implementation-specific limits on
otherwise unconstrained inputs, e.g. to prevent denial of service
attacks, to guard against running out of memory, or to work around
platform-specific limitations. For example implementations might
impose limit on frame sizes and the total message size after
reassembly from multiple frames.
10.5. WebSocket client authentication
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, TLS
authentication. authentication.
If at any time a server is faced with data that it does not 10.6. Connection confidentiality and integrity
understand, or that violates some criteria by which the server
determines safety of input, or when the server sees an opening Communications confidentiality and integrity is provided by running
handshake that does not correspond to the values the server is the WebSocket protocol over TLS (wss URIs).
expecting (e.g. incorrect path or origin), the server MAY drop the
TCP connection. If the invalid data received after a successful For connections using TLS, the amount of benefit provided by TLS
WebSocket handshake, the server SHOULD send a Close frame with an depends greatly on the strength of the algorithms negotiated during
appropriate status code Section 7.4 before proceeding to _Close the the TLS handshake. For example some TLS cipher mechanisms don't
WebSocket Connection_. Use of a Close frame with an appropriate provide connection confidentiality. To achieve reasonable levels of
status code can help in diagnosing the problem. If the invalid data protections, clients should use only Strong TLS algorithms. "Web
is sent during the WebSocket handshake the server SHOULD return an Security Context: User Interface Guidelines"
appropriate HTTP [RFC2616] status code. [W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS
algorithms.
10.7. Handling of invalid data
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
understand, or that violates some criteria by which the endpoint
determines safety of input, or when the endpoint sees an opening
handshake that does not correspond to the values it is expecting
(e.g. incorrect path or origin in the client request), the endpoint
MAY drop the TCP connection. If the invalid data received after a
successful WebSocket handshake, the endpoint SHOULD send a Close
frame with an appropriate status code Section 7.4 before proceeding
to _Close the WebSocket Connection_. Use of a Close frame with an
appropriate status code can help in diagnosing the problem. If the
invalid data is sent during the WebSocket handshake the server SHOULD
return an appropriate HTTP [RFC2616] status code.
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.
In addition to endpoints being the target of attacks via WebSockets,
other parts of web infrastructure, such as proxies, may be the
subject of an attack. In particular, an intermediary may interpret a
WebSocket frame from a client as a request, and a frame from the
server as a response to that request. For instance, an attacker
could get a browser to establish a connection to its server, get the
browser to send a frame that looks to an intermediary like a GET
request for a common piece of JavaScript on another domain, and send
back a frame that is interpreted as a cacheable response to that
request, thus poisioning the cache for other users. To prevent this
attack, frames sent from clients are masked on the wire with a 32-bit
value, to prevent an attacker from controlling the bits on the wire
and thus lessen the probability of an attacker being able to
construct a frame that can be misinterpreted by a proxy as a non-
WebSocket request.
For connections using TLS (wss: URIs), the amount of benefit provided
by TLS depends greatly on the strength of the algorithms negotiated
during the TLS handshake. For example some TLS cipher mechanisms
don't provide connection confidentiality. To achieve reasonable
levels of protections, clients should use only Strong TLS algorithms.
"Web Security Context: User Interface Guidelines"
[W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS
algorithms.
Implementations MAY impose implementation-specific limits on
otherwise unconstrained inputs, e.g. to prevent denial of service
attacks, to guard against running out of memory, or to work around
platform-specific limitations. For example implementations might
impose limit on frame sizes and the total message size after
reassembly from multiple frames.
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
Status. Status.
Permanent. Permanent.
URI scheme syntax. URI scheme syntax.
In ABNF terms using the terminals from the URI specifications: In ABNF terms using the terminals from the URI specifications:
[RFC5234] [RFC3986] [RFC5234] [RFC3986]
skipping to change at page 53, line 17 skipping to change at page 57, line 17
Contact. Contact.
HYBI WG <hybi@ietf.org> HYBI WG <hybi@ietf.org>
Author/Change controller. Author/Change controller.
IETF <iesg@ietf.org> IETF <iesg@ietf.org>
References. References.
RFC XXXX RFC XXXX
11.1.2. Registration of "wss:" Scheme 11.1.2. Registration of "wss" Scheme
A |wss:| URI identifies a WebSocket server and resource name, and A |wss| URI identifies a WebSocket server and resource name, and
indicates that traffic over that connection is to be protected via indicates that traffic over that connection is to be protected via
TLS (including standard benefits of TLS such as data confidentiality TLS (including standard benefits of TLS such as data confidentiality
and integrity, and endpoint authentication). and integrity, and endpoint authentication).
URI scheme name. URI scheme name.
wss wss
Status. Status.
Permanent. Permanent.
skipping to change at page 58, line 41 skipping to change at page 62, line 41
Extension Definition Extension Definition
A reference to the document in which the extension being used with A reference to the document in which the extension being used with
the WebSocket protocol is defined. the WebSocket protocol is defined.
Known Incompatible Extensions Known Incompatible Extensions
A list of extension identifiers with which this extension is known A list of extension identifiers with which this extension is known
to be incompatible. to be incompatible.
WebSocket Extension names are to be subject to "First Come First WebSocket Extension names are to be subject to "First Come First
Served" IANA registration policy [RFC5226], with the exception of Served" IANA registration policy [RFC5226].
WebSocket Extension names whose Extension Identifier matches a
private-use-token as defined in Section 9.1 (values beginning with
"x-"). These Extension Identifiers matching private-use-token are
reserved for Experimental Use as per RFC5226 [RFC5226].
There are no initial values in this registry. There are no initial values in this registry.
11.5. WebSocket Subprotocol Name Registry 11.5. WebSocket Subprotocol 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 Subprotocol names to be used with the WebSocket protocol in WebSocket Subprotocol 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
skipping to change at page 60, line 37 skipping to change at page 64, line 31
| 7 + draft-ietf-hybi-thewebsocketprotocol-07 | | 7 + draft-ietf-hybi-thewebsocketprotocol-07 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 8 + draft-ietf-hybi-thewebsocketprotocol-08 | | 8 + draft-ietf-hybi-thewebsocketprotocol-08 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 9 + Reserved | | 9 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 10 + Reserved | | 10 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 11 + Reserved | | 11 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 12 + Reserved |
-+----------------+-----------------------------------------+-
| 13 + draft-ietf-hybi-thewebsocketprotocol-13 |
-+----------------+-----------------------------------------+-
11.7. WebSocket Close Code Number Registry 11.7. WebSocket Close Code Number Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Connection Close Code Numbers in accordance with the WebSocket Connection Close Code Numbers in accordance with the
principles set out in RFC 5226 [RFC5226]. principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
skipping to change at page 62, line 15 skipping to change at page 66, line 15
|Status Code | Meaning | Contact | Reference | |Status Code | Meaning | Contact | Reference |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1000 | Normal Closure | hybi@ietf.org | RFC XXXX | | 1000 | Normal Closure | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1001 | Going Away | hybi@ietf.org | RFC XXXX | | 1001 | Going Away | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 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 | Frame Too Large | 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 UTF-8 | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1008 | Policy Violation| hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------|
| 1009 | Message Too Big | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------|
| 1010 | Mandatory Ext. | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------|
11.8. WebSocket Opcode Registry 11.8. WebSocket Opcode Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Opcodes in accordance with the principles set out in RFC WebSocket Opcodes in accordance with the principles set out in RFC
5226 [RFC5226]. 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
skipping to change at page 65, line 38 skipping to change at page 69, line 38
special thank you to the responsible Area Director Peter Saint-Andre. special thank you to the responsible Area Director Peter Saint-Andre.
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. Note that people listed above didn't necessarily Mykyta Yevstifeyev, Len Holgate, Paul Colomiets, Piotr Kulaga, Brian
endorsed the end result of this work. Raymor, Jan Koehler, Joonas Lehtolahti. Note that people listed
above didn't necessarily endorsed 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 67, line 26 skipping to change at page 71, line 26
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-websec-origin] [I-D.ietf-websec-origin]
Barth, A., "The Web Origin Concept", Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-02 (work in progress), June 2011. draft-ietf-websec-origin-04 (work in progress),
August 2011.
14.2. Informative References 14.2. Informative References
[WSAPI] Hickson, I., "The Web Sockets API", August 2010, [WSAPI] Hickson, I., "The Web Sockets API", August 2010,
<http://dev.w3.org/html5/websockets/>. <http://dev.w3.org/html5/websockets/>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
 End of changes. 80 change blocks. 
284 lines changed or deleted 508 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/