draft-ietf-hybi-thewebsocketprotocol-09.txt   draft-ietf-hybi-thewebsocketprotocol-10.txt 
HyBi Working Group I. Fette HyBi Working Group I. Fette
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track June 13, 2011 Intended status: Standards Track A. Melnikov
Expires: December 15, 2011 Expires: January 12, 2012 Isode Ltd
July 11, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-09 draft-ietf-hybi-thewebsocketprotocol-10
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. (In handshake followed by basic message framing, layered over TCP. The
theory, any transport protocol could be used so long as it provides goal of this technology is to provide a mechanism for browser-based
for reliable transport, is byte clean, and supports relatively large applications that need two-way communication with servers that does
message sizes. However, for this document, we consider only TCP.) not rely on opening multiple HTTP connections (e.g. using
The goal of this technology is to provide a mechanism for browser-
based applications that need two-way communication with servers that
does not rely on opening multiple HTTP connections (e.g. using
XMLHttpRequest or <iframe>s and long polling). XMLHttpRequest or <iframe>s and long polling).
Please send feedback to the hybi@ietf.org mailing list. Please send feedback to the hybi@ietf.org mailing list.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 15, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 43
4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . 22 4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . 22
4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 24 4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 24
4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 25 4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 25
5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 27 5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 27 5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 27
5.2. Server-side Requirements . . . . . . . . . . . . . . . . 32 5.2. Server-side Requirements . . . . . . . . . . . . . . . . 32
5.2.1. Reading the Client's Opening Handshake . . . . . . . . 32 5.2.1. Reading the Client's Opening Handshake . . . . . . . . 33
5.2.2. Sending the Server's Opening Handshake . . . . . . . . 33 5.2.2. Sending the Server's Opening Handshake . . . . . . . . 33
6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 37 6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 37
6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . 37 6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . 37
6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . 37 6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . 37
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 39 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 39
7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39
7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 39 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 39
7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 39 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 39
7.1.3. The WebSocket Closing Handshake is Started . . . . . . 39 7.1.3. The WebSocket Closing Handshake is Started . . . . . . 39
7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 40 7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 40
skipping to change at page 3, line 19 skipping to change at page 3, line 18
7.1.6. The WebSocket Connection Close Reason . . . . . . . . 40 7.1.6. The WebSocket Connection Close Reason . . . . . . . . 40
7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 41 7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 41
7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 41 7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 41
7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 41 7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 41
7.2.2. Server-initiated closure . . . . . . . . . . . . . . . 42 7.2.2. Server-initiated closure . . . . . . . . . . . . . . . 42
7.3. Normal Closure of Connections . . . . . . . . . . . . . . 42 7.3. Normal Closure of Connections . . . . . . . . . . . . . . 42
7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 42 7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 42
7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 42 7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 42
7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 43 7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 43
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Handling Errors in UTF-8 from the Server . . . . . . . . 45 8.1. Handling Errors in UTF-8 Encoded Data . . . . . . . . . . 45
8.2. Handling Errors in UTF-8 from the Client . . . . . . . . 45
9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . 46 9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . 46
9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . 47 9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . 47
9.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 47 9.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
11.1. Registration of "ws:" Scheme . . . . . . . . . . . . . . 51 11.1. Registration of "ws:" Scheme . . . . . . . . . . . . . . 51
11.2. Registration of "wss:" Scheme . . . . . . . . . . . . . . 52 11.2. Registration of "wss:" Scheme . . . . . . . . . . . . . . 52
11.3. Registration of the "WebSocket" HTTP Upgrade Keyword . . 53 11.3. Registration of the "WebSocket" HTTP Upgrade Keyword . . 53
11.4. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . . . 53 11.4. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . . . 53
skipping to change at page 3, line 47 skipping to change at page 3, line 45
11.11. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 58 11.11. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 58
11.12. WebSocket Version Number Registry . . . . . . . . . . . . 59 11.12. WebSocket Version Number Registry . . . . . . . . . . . . 59
11.13. WebSocket Close Code Number Registry . . . . . . . . . . 60 11.13. WebSocket Close Code Number Registry . . . . . . . . . . 60
11.14. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 61 11.14. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 61
11.15. WebSocket Framing Header Bits Registry . . . . . . . . . 62 11.15. WebSocket Framing Header Bits Registry . . . . . . . . . 62
12. Using the WebSocket protocol from Other Specifications . . . . 63 12. Using the WebSocket protocol from Other Specifications . . . . 63
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1. Normative References . . . . . . . . . . . . . . . . . . 65 14.1. Normative References . . . . . . . . . . . . . . . . . . 65
14.2. Informative References . . . . . . . . . . . . . . . . . 66 14.2. Informative References . . . . . . . . . . . . . . . . . 66
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
1.1. Background 1.1. Background
_This section is non-normative._ _This section is non-normative._
Historically, creating an instant messenger chat client as a Web Historically, creating Web applications that need bidirectional
application has required an abuse of HTTP to poll the server for communication between a client and a server (e.g., instant messaging
updates while sending upstream notifications as distinct HTTP and gaming applications) has required an abuse of HTTP to poll the
calls.[RFC6202] server for updates while sending upstream notifications as distinct
HTTP calls.[RFC6202]
This results in a variety of problems: This results in a variety of problems:
o The server is forced to use a number of different underlying TCP o The server is forced to use a number of different underlying TCP
connections for each client: one for sending information to the connections for each client: one for sending information to the
client, and a new one for each incoming message. client, and a new one for each incoming message.
o The wire protocol has a high overhead, with each client-to-server o The wire protocol has a high overhead, with each client-to-server
message having an HTTP header. message having an HTTP header.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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.
The leading line from the server follows the Status-Line format. The The leading line from the server follows the Status-Line format. The
Request-Line and Status-Line productions are defined in [RFC2616]. Request-Line and Status-Line productions are defined in [RFC2616].
After the leading line in both cases come an unordered set of header After the leading line in both cases come an unordered set of header
fields. The meaning of these header fields is specified in Section 5 fields. The meaning of these header fields is specified in Section 5
of this document. Additional header fields may also be present, such of this document. Additional header fields may also be present, such
as cookies [I-D.ietf-httpstate-cookie] required to identify the user. as cookies [RFC6265] required to identify the user. The format and
The format and parsing of headers is as defined in [RFC2616]. parsing of headers is as 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". A message is a complete unit of data at an application
level, with the expectation that many or most applications level, with the expectation that many or most applications
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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==
Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 8 Sec-WebSocket-Version: 8
Headers in the handshake are sent by the client in a random order; In compliance with [RFC2616], header fields in the handshake may be
the order is not meaningful. sent by the client in any order, so the order in which different
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 of its handshake The client includes the hostname in the Host header of its handshake
as per [RFC2616], so that both the client and the server can verify as per [RFC2616], so that both the client and the server can verify
that they agree on which host is in use. that they agree on which host is in use.
skipping to change at page 7, line 29 skipping to change at page 7, line 29
clients this header may be sent if it makes sense in the context of clients this header may be sent if it makes sense in the context of
those clients. those clients.
NOTE: It is worth noting that for the attack cases this header NOTE: It is worth noting that for the attack cases this header
protects against, the untrusted party is typically the author of a protects against, the untrusted party is typically the author of a
JavaScript application that is executing in the context of the JavaScript application that is executing in the context of the
client. The client itself can contact the server and via the client. The client itself can contact the server and via the
mechanism of the |Sec-WebSocket-Origin| header, determine whether to mechanism of the |Sec-WebSocket-Origin| header, determine whether to
extend those communication privileges to the JavaScript application. extend those communication privileges to the JavaScript application.
A JavaScript application cannot set a header starting with "Sec-" via A JavaScript application cannot set a header starting with "Sec-" via
XHR. The intent is not to prevent non-browsers from establishing XMLHttpRequest. The intent is not to prevent non-browsers from
connections, but rather to ensure that browsers under the control of establishing connections, but rather to ensure that browsers under
potentially malicious JavaScript cannot fake a WebSocket handshake. the control of potentially malicious JavaScript cannot fake a
WebSocket handshake.
Finally, the server has to prove to the client that it received the Finally, the server has to prove to the client that it received the
client's WebSocket handshake, so that the server doesn't accept client's WebSocket handshake, so that the server doesn't accept
connections that are not WebSocket connections. This prevents an connections that are not WebSocket connections. This prevents an
attacker from tricking a WebSocket server by sending it carefully- attacker from tricking a WebSocket server by sending it carefully-
crafted packets using |XMLHttpRequest| or a |form| submission. crafted packets using |XMLHttpRequest| or a |form| submission.
To prove that the handshake was received, the server has to take two To prove that the handshake was received, the server has to take two
pieces of information and combine them to form a response. The first pieces of information and combine them to form a response. The first
piece of information comes from the |Sec-WebSocket-Key| header in the piece of information comes from the |Sec-WebSocket-Key| header in the
client handshake: client handshake:
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
For this header, the server has to take the value (as present in the For this header, the server has to take the value (as present in the
header, e.g. the base64-encoded [RFC4648] version minus leading and header, e.g. the base64-encoded [RFC4648] version minus any leading
trailing whitespace), and concatenate this with the GUID "258EAFA5- and trailing whitespace), and concatenate this with the GUID
E914-47DA-95CA-C5AB0DC85B11" in string form, which is unlikely to be "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form, which is
used by network endpoints that do not understand the WebSocket unlikely to be used by network endpoints that do not understand the
protocol. A SHA-1 hash (160 bits), base64-encoded, of this WebSocket protocol. A SHA-1 hash (160 bits), base64-encoded (see
concatenation is then returned in the server's handshake Section 4 of [RFC4648]), of this concatenation is then returned in
the server's handshake [FIPS.180-2.2002].
[FIPS.180-2.2002].
Concretely, if as in the example above, header |Sec-WebSocket-Key| Concretely, if as in the example above, header |Sec-WebSocket-Key|
had the value "dGhlIHNhbXBsZSBub25jZQ==", the server would had the value "dGhlIHNhbXBsZSBub25jZQ==", the server would
concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form
the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
C5AB0DC85B11". The server would then take the SHA-1 hash of this, C5AB0DC85B11". The server would then take the SHA-1 hash of this,
giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6
0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is
then base64-encoded, to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+ then base64-encoded (see Section 4 of [RFC4648]), to give the value
xOo=". This value would then be echoed in the header |Sec-WebSocket- "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=". This value would then be echoed in
Accept|. the header |Sec-WebSocket-Accept|.
The handshake from the server is much simpler than the client The handshake from the server is much simpler than the client
handshake. The first line is an HTTP Status-Line, with the status handshake. The first line is an HTTP Status-Line, with the status
code 101: code 101:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Any status code other than 101 indicates that the WebSocket handshake Any status code other than 101 indicates that the WebSocket handshake
has not completed, and that the semantics of HTTP still apply. The has not completed, and that the semantics of HTTP still apply. The
headers follow the status code. headers follow the status code.
skipping to change at page 9, line 35 skipping to change at page 9, line 37
After sending a control frame indicating the connection should be After sending a control frame indicating the connection should be
closed, a peer does not send any further data; after receiving a closed, a peer does not send any further data; after receiving a
control frame indicating the connection should be closed, a peer control frame indicating the connection should be closed, a peer
discards any further data received. discards any further data received.
It is safe for both peers to initiate this handshake simultaneously. It is safe for both peers to initiate this handshake simultaneously.
The closing handshake is intended to complement the TCP closing The closing handshake is intended to complement the TCP closing
handshake (FIN/ACK), on the basis that the TCP closing handshake is handshake (FIN/ACK), on the basis that the TCP closing handshake is
not always reliable end-to-end, especially in the presence of man-in- not always reliable end-to-end, especially in the presence of
the-middle proxies and other intermediaries. intercepting proxies and other intermediaries.
By sending a close frame and waiting for a close frame in response, By sending a close frame and waiting for a close frame in response,
certain cases are avoided where data may be unnecessarily lost. For certain cases are avoided where data may be unnecessarily lost. For
instance, on some platforms, if a socket is closed with data in the instance, on some platforms, if a socket is closed with data in the
receive queue, a RST packet is sent, which will then cause recv() to receive queue, a RST packet is sent, which will then cause recv() to
fail for the party that received the RST, even if there was data fail for the party that received the RST, even if there was data
waiting to be read. waiting to be read.
1.5. Design Philosophy 1.5. Design Philosophy
_This section is non-normative._ _This section is non-normative._
The WebSocket protocol is designed on the principle that there should The WebSocket protocol is designed on the principle that there should
be minimal framing (the only framing that exists is to make the be minimal framing (the only framing that exists is to make the
protocol frame-based instead of stream-based, and to support a protocol frame-based instead of stream-based, and to support a
distinction between Unicode text and binary frames). It is expected distinction between Unicode text and binary frames). It is expected
that metadata would be layered on top of WebSocket by the application that metadata would be layered on top of WebSocket by the application
layer, in the same way that metadata is layered on top of TCP by the layer, in the same way that metadata is layered on top of TCP by the
application layer (HTTP). application layer (e.g., HTTP).
Conceptually, WebSocket is really just a layer on top of TCP that Conceptually, WebSocket is really just a layer on top of TCP that
adds a Web "origin"-based security model for browsers; adds an does the following:
addressing and protocol naming mechanism to support multiple services
on one port and multiple host names on one IP address; layers a o adds a Web "origin"-based security model for browsers
framing mechanism on top of TCP to get back to the IP packet
mechanism that TCP is built on, but without length limits; and o adds an addressing and protocol naming mechanism to support
includes an additional closing handshake in-band that is designed to multiple services on one port and multiple host names on one IP
work in the presence of proxies and other intermediaries. Other than address;
that, it adds nothing. Basically it is intended to be as close to
just exposing raw TCP to script as possible given the constraints of o layers a framing mechanism on top of TCP to get back to the IP
the Web. It's also designed in such a way that its servers can share packet mechanism that TCP is built on, but without length limits
a port with HTTP servers, by having its handshake be a valid HTTP
Upgrade request mechanism also. o includes an additional closing handshake in-band that is designed
to work in the presence of proxies and other intermediaries
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
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
be a valid HTTP Upgrade request mechanism also.
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 11, line 42 skipping to change at page 12, line 4
set of hosts for WebSocket connections separate from the HTTP servers set of hosts for WebSocket connections separate from the HTTP servers
is probably easier to manage. At the time of writing of this is probably easier to manage. At the time of writing of this
specification, it should be noted that connections on port 80 and 443 specification, it should be noted that connections on port 80 and 443
have significantly different success rates, with connections on port have significantly different success rates, with connections on port
443 being significantly more likely to succeed, though this may 443 being significantly more likely to succeed, though this may
change with time. change with time.
1.9. Subprotocols Using the WebSocket protocol 1.9. Subprotocols Using the WebSocket protocol
_This section is non-normative._ _This section is non-normative._
The client can request that the server use a specific subprotocol by The client can request that the server use a specific subprotocol by
including the |Sec-WebSocket-Protocol| field in its handshake. If it including the |Sec-WebSocket-Protocol| field in its handshake. If it
is specified, the server needs to include the same field and one of is specified, the server needs to include the same field and one of
the selected subprotocol values in its response for the connection to the selected subprotocol values in its response for the connection to
be established. be established.
These subprotocol names should be registered as per Section 11.10. These subprotocol names should be registered as per Section 11.10.
To avoid potential collisions, it is recommended to use names that To avoid potential collisions, it is recommended to use names that
contain the domain name of the subprotocol's originator. For contain the ASCII version of the domain name of the subprotocol's
example, if Example Corporation were to create a Chat subprotocol to originator. For example, if Example Corporation were to create a
be implemented by many servers around the Web, they could name it Chat subprotocol to be implemented by many servers around the Web,
"chat.example.com". If the Example Organization called their they could name it "chat.example.com". If the Example Organization
competing subprotocol "chat.example.org", then the two subprotocols called their competing subprotocol "chat.example.org", then the two
could be implemented by servers simultaneously, with the server subprotocols could be implemented by servers simultaneously, with the
dynamically selecting which subprotocol to use based on the value server dynamically selecting which subprotocol to use based on the
sent by the client. value sent by the client.
Subprotocols can be versioned in backwards-incompatible ways by Subprotocols can be versioned in backwards-incompatible ways by
changing the subprotocol name, e.g. going from "bookings.example.net" changing the subprotocol name, e.g. going from "bookings.example.net"
to "v2.bookings.example.net". These subprotocols would be considered to "v2.bookings.example.net". These subprotocols would be considered
completely separate by WebSocket clients. Backwards-compatible completely separate by WebSocket clients. Backwards-compatible
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
skipping to change at page 15, line 22 skipping to change at page 15, line 22
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ] wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
host = <host, defined in [RFC3986], Section 3.2.2> host = <host, defined in [RFC3986], Section 3.2.2>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, defined in [RFC3986], Section 3.2.3>
path = <path-abempty, defined in [RFC3986], Section 3.3> path = <path-abempty, defined in [RFC3986], Section 3.3>
query = <query, defined in [RFC3986], Section 3.4> query = <query, defined in [RFC3986], Section 3.4>
The port component is OPTIONAL; the default for "ws" is port 80, The port component is OPTIONAL; the default for "ws" is port 80,
while the default for "wss" is port 443. while the default for "wss" is port 443.
The URI is called "secure" if the scheme component matches "wss" The URI is called "secure" (and it said that "the secure flag is
case-insensitively. set") if the scheme component matches "wss" case-insensitively.
The "resource-name" can be constructed by concatenating The "resource-name" (also known as /resource name/ in Section 5.1)
can be constructed by concatenating
o "/" if the path component is empty o "/" if the path component is empty
o the path component o the path component
o "?" if the query component is non-empty o "?" if the query component is non-empty
o the query component o the query component
Fragment identifiers are meaningless in the context of WebSocket Fragment identifiers are meaningless in the context of WebSocket
skipping to change at page 17, line 21 skipping to change at page 17, line 21
MUST be 0 unless an extension is negotiated which defines meanings MUST be 0 unless an extension is negotiated which defines meanings
for non-zero values. If a nonzero value is received and none of for non-zero values. If a nonzero value is received and none of
the negotiated extensions defines the meaning of such a nonzero the negotiated extensions defines the meaning of such a nonzero
value, the receiving endpoint MUST _Fail the WebSocket value, the receiving endpoint MUST _Fail the WebSocket
Connection_. Connection_.
Opcode: 4 bits Opcode: 4 bits
Defines the interpretation of the payload data. If an unknown Defines the interpretation of the payload data. If an unknown
opcode is received, the receiving endpoint MUST ignore that frame. opcode is received, the receiving endpoint MUST _Fail the
The following values are defined. WebSocket Connection_. The following values are defined.
* %x0 denotes a continuation frame * %x0 denotes a continuation frame
* %x1 denotes a text frame * %x1 denotes a text frame
* %x2 denotes a binary frame * %x2 denotes a binary frame
* %x3-7 are reserved for further non-control frames * %x3-7 are reserved for further non-control frames
* %x8 denotes a connection close * %x8 denotes a connection close
skipping to change at page 19, line 8 skipping to change at page 19, line 8
frame-rsv3 frame-rsv3
frame-opcode frame-opcode
frame-masked frame-masked
frame-payload-length frame-payload-length
[ frame-masking-key ] [ frame-masking-key ]
frame-payload-data frame-payload-data
frame-fin = %x0 ; more frames of this message follow frame-fin = %x0 ; more frames of this message follow
/ %x1 ; final frame of this message / %x1 ; final frame of this message
frame-rsv1 = %x0 ; 1 bit, MUST be 0 frame-rsv1 = %x0
; 1 bit, MUST be 0 unless negotiated otherwise
frame-rsv2 = %x0 ; 1 bit, MUST be 0 frame-rsv2 = %x0
; 1 bit, MUST be 0 unless negotiated otherwise
frame-rsv3 = %x0 ; 1 bit, MUST be 0 frame-rsv3 = %x0
; 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
skipping to change at page 20, line 41 skipping to change at page 20, line 41
mask the data as to unmask the data. mask the data as to unmask the data.
Octet i of the transformed data ("transformed-octet-i") is the XOR of Octet i of the transformed data ("transformed-octet-i") is the XOR of
octet i of the original data ("original-octet-i") with octet i modulo octet i of the original data ("original-octet-i") with octet i modulo
4 of the masking key ("masking-key-octet-j"): 4 of the masking key ("masking-key-octet-j"):
j = i MOD 4 j = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j transformed-octet-i = original-octet-i XOR masking-key-octet-j
When preparing a masked frame, the client MUST pick a fresh masking When preparing a masked frame, the client MUST pick a fresh masking
key uniformly at random from the set of allowed 32-bit values. The key from the set of allowed 32-bit values. The masking key must be
unpredictability of the masking key is essential to prevent the unpredictable. The unpredictability of the masking key is essential
author of malicious applications from selecting the bytes that appear to prevent the author of malicious applications from selecting the
on the wire. bytes that appear on the wire.
The payload length, indicated in the framing as frame-payload-length, The payload length, indicated in the framing as frame-payload-length,
does NOT include the length of the masking key. It is the length of does NOT include the length of the masking key. It is the length of
the payload data, e.g. the number of bytes following the masking key. the payload data, e.g. the number of bytes following the masking key.
4.4. Fragmentation 4.4. Fragmentation
The primary purpose of fragmentation is to allow sending a message The primary purpose of fragmentation is to allow sending a message
that is of unknown size when the message is started without having to that is of unknown size when the message is started without having to
buffer that message. If messages couldn't be fragmented, then an buffer that message. If messages couldn't be fragmented, then an
skipping to change at page 26, line 7 skipping to change at page 26, line 7
The protocol is designed to allow for extensions, which will add The protocol is designed to allow for extensions, which will add
capabilities to the base protocols. The endpoints of a connection capabilities to the base protocols. The endpoints of a connection
MUST negotiate the use of any extensions during the opening MUST negotiate the use of any extensions during the opening
handshake. This specification provides opcodes 0x3 through 0x7 and handshake. This specification provides opcodes 0x3 through 0x7 and
0xB through 0xF, the extension data field, and the frame-rsv1, frame- 0xB through 0xF, the extension data field, and the frame-rsv1, frame-
rsv2, and frame-rsv3 bits of the frame header for use by extensions. rsv2, and frame-rsv3 bits of the frame header for use by extensions.
The negotiation of extensions is discussed in further detail in The negotiation of extensions is discussed in further detail in
Section 9.1. Below are some anticipated uses of extensions. This Section 9.1. Below are some anticipated uses of extensions. This
list is neither complete nor proscriptive. list is neither complete nor prescriptive.
o Extension data may be placed in the payload data before the o Extension data may be placed in the payload data before the
application data. application data.
o Reserved bits can be allocated for per-frame needs. o Reserved bits can be allocated for per-frame needs.
o Reserved opcode values can be defined. o Reserved opcode values can be defined.
o Reserved bits can be allocated to the opcode field if more opcode o Reserved bits can be allocated to the opcode field if more opcode
values are needed. values are needed.
skipping to change at page 27, line 19 skipping to change at page 27, line 19
To _Establish a WebSocket Connection_, a client opens a connection To _Establish a WebSocket Connection_, a client opens a connection
and sends a handshake as defined in this section. A connection is and sends a handshake as defined in this section. A connection is
defined to initially be in a CONNECTING state. A client will need to defined to initially be in a CONNECTING state. A client will need to
supply a /host/, /port/, /resource name/, and a /secure/ flag, which supply a /host/, /port/, /resource name/, and a /secure/ flag, which
are the components of a WebSocket URI as discussed in Section 3, are the components of a WebSocket URI as discussed in Section 3,
along with a list of /protocols/ and /extensions/ to be used. along with a list of /protocols/ and /extensions/ to be used.
Additionally, if the client is a web browser, an /origin/ MUST be Additionally, if the client is a web browser, an /origin/ MUST be
supplied. supplied.
Clients running in controlled environments, e.g. browsers on mobile Clients running in controlled environments, e.g. browsers on mobile
handsets tied to specific carriers, may offload the management of the handsets tied to specific carriers, MAY offload the management of the
connection to another agent on the network. In such a situation, the connection to another agent on the network. In such a situation, the
client for the purposes of conformance is considered to include both client for the purposes of conformance is considered to include both
the handset software and any such agents. the handset software and any such agents.
When the client is to _Establish a WebSocket Connection_ given a set When the client is to _Establish a WebSocket Connection_ given a set
of (/host/, /port/, /resource name/, and /secure/ flag), along with a of (/host/, /port/, /resource name/, and /secure/ flag), along with a
list of /protocols/ and /extensions/ to be used, and an /origin/ in list of /protocols/ and /extensions/ to be used, and an /origin/ in
the case of web browsers, it MUST open a connection, send an opening the case of web browsers, it MUST open a connection, send an opening
handshake, and read the server's handshake in response. The exact handshake, and read the server's handshake in response. The exact
requirements of how the connection should be opened, what should be requirements of how the connection should be opened, what should be
skipping to change at page 28, line 6 skipping to change at page 28, line 6
to have failed. There MUST be no more than one connection in a to have failed. There MUST be no more than one connection in a
CONNECTING state. If multiple connections to the same IP address CONNECTING state. If multiple connections to the same IP address
are attempted simultaneously, the client MUST serialize them so are attempted simultaneously, the client MUST serialize them so
that there is no more than one connection at a time running that there is no more than one connection at a time running
through the following steps. through the following steps.
If the client cannot determine the IP address of the remote host If the client cannot determine the IP address of the remote host
(for example because all communication is being done through a (for example because all communication is being done through a
proxy server that performs DNS queries itself), then the client proxy server that performs DNS queries itself), then the client
MUST assume for the purposes of this step that each host name MUST assume for the purposes of this step that each host name
refers to a distinct remote host, and should instead limit the refers to a distinct remote host, and instead the client SHOULD
total number of simultaneous connections that are not established limit the total number of simultaneous pending connections to a
to a reasonably low number (e.g., in a Web browser, simultaneous reasonably low number (e.g., the client might allow simultaneous
pending connections to a.example.com and b.example.com would be pending connections to a.example.com and b.example.com, but if
allowed, but if thirty connections are requested, that may not be thirty simultaneous connections to a single host are requested,
allowed. The limit should consider the number of tabs the user that may not be allowed). In a Web browser context, the client
has open. SHOULD consider the number of tabs the user has open in setting a
limit to the number of simultaneous pending connections.
NOTE: This makes it harder for a script to perform a denial of NOTE: This makes it harder for a script to perform a denial of
service attack by just opening a large number of WebSocket service attack by just opening a large number of WebSocket
connections to a remote host. A server can further reduce the connections to a remote host. A server can further reduce the
load on itself when attacked by making use of this by pausing load on itself when attacked by pausing before closing the
before closing the connection, as that will reduce the rate at connection, as that will reduce the rate at which the client
which the client reconnects. reconnects.
NOTE: There is no limit to the number of established WebSocket NOTE: There is no limit to the number of established WebSocket
connections a client can have with a single remote host. Servers connections a client can have with a single remote host. Servers
can refuse to accept connections from hosts with an excessive can refuse to accept connections from hosts/IP addresses with an
number of existing connections, or disconnect resource-hogging excessive number of existing connections, or disconnect resource-
connections when suffering high load. hogging connections when suffering high load.
3. _Proxy Usage_: If the client is configured to use a proxy when 3. _Proxy Usage_: If the client is configured to use a proxy when
using the WebSocket protocol to connect to host /host/ and/or using the WebSocket protocol to connect to host /host/ and port
port /port/, then the client SHOULD connect to that proxy and ask /port/, then the client SHOULD connect to that proxy and ask it
it to open a TCP connection to the host given by /host/ and the to open a TCP connection to the host given by /host/ and the port
port given by /port/. given by /port/.
EXAMPLE: For example, if the client uses an HTTP proxy for all EXAMPLE: For example, if the client uses an HTTP proxy for all
traffic, then if it was to try to connect to port 80 on server traffic, then if it was to try to connect to port 80 on server
example.com, it might send the following lines to the proxy example.com, it might send the following lines to the proxy
server: server:
CONNECT example.com:80 HTTP/1.1 CONNECT example.com:80 HTTP/1.1
Host: example.com Host: example.com
If there was a password, the connection might look like: If there was a password, the connection might look like:
skipping to change at page 29, line 7 skipping to change at page 29, line 8
CONNECT example.com:80 HTTP/1.1 CONNECT example.com:80 HTTP/1.1
Host: example.com Host: example.com
Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE= Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE=
If the client is not configured to use a proxy, then a direct TCP If the client is not configured to use a proxy, then a direct TCP
connection SHOULD be opened to the host given by /host/ and the connection SHOULD be opened to the host given by /host/ and the
port given by /port/. port given by /port/.
NOTE: Implementations that do not expose explicit UI for NOTE: Implementations that do not expose explicit UI for
selecting a proxy for WebSocket connections separate from other selecting a proxy for WebSocket connections separate from other
proxies are encouraged to use a SOCKS proxy for WebSocket proxies are encouraged to use a SOCKS5 [RFC1928] proxy for
connections, if available, or failing that, to prefer the proxy WebSocket connections, if available, or failing that, to prefer
configured for HTTPS connections over the proxy configured for the proxy configured for HTTPS connections over the proxy
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).
skipping to change at page 30, line 23 skipping to change at page 30, line 24
5. The request MUST contain an "Upgrade" header whose value is 5. The request MUST contain an "Upgrade" header whose value is
equal to "websocket". equal to "websocket".
6. The request MUST contain a "Connection" header whose value MUST 6. The request MUST contain a "Connection" header whose value MUST
include the "Upgrade" token. include the "Upgrade" token.
7. The request MUST include a header with the name "Sec-WebSocket- 7. The request MUST include a header with the name "Sec-WebSocket-
Key". The value of this header MUST be a nonce consisting of a Key". The value of this header MUST be a nonce consisting of a
randomly selected 16-byte value that has been base64-encoded randomly selected 16-byte value that has been base64-encoded
[RFC3548]. The nonce MUST be selected randomly for each (see Section 4 of [RFC4648]). The nonce MUST be selected
connection. randomly for each connection.
NOTE: As an example, if the randomly selected value was the NOTE: As an example, if the randomly selected value was the
sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header
would be "AQIDBAUGBwgJCgsMDQ4PEC==" would be "AQIDBAUGBwgJCgsMDQ4PEC=="
8. The request MUST include a header with the name "Sec-WebSocket- 8. The request MUST include a header with the name "Sec-WebSocket-
Origin" if the request is coming from a browser client. If the Origin" if the request is coming from a browser client. If the
connection is from a non-browser client, the request MAY include connection is from a non-browser client, the request MAY include
this header if the semantics of that client match the use-case this header if the semantics of that client match the use-case
skipping to change at page 31, line 4 skipping to change at page 31, line 6
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 would be "http://www.example.com". header would be "http://www.example.com".
9. The request MUST include a header with the name "Sec-WebSocket- 9. The request MUST include a header with the name "Sec-WebSocket-
Version". The value of this header MUST be 8. _Note: Although a Version". The value of this header MUST be 8. _Note: Although a
draft -09 was published, as -09 was comprised of editorial draft -09 was published, as -09 was comprised of editorial
changes and not changes to the wire protocol, 9 was not used as changes and not changes to the wire protocol, 9 was not used as
a valid value for Sec-WebSocket-Version. This value was a valid value for Sec-WebSocket-Version. This value was
reserved in the IANA registry but was not and will not be used. reserved in the IANA registry but was not and will not be used.
If subsequent changes to the wire protocol are necessary, 9 will If subsequent changes to the wire protocol are necessary, 9 will
be skipped to prevent confusion with the draft 9 protocol._ be skipped to prevent confusion with the draft 9 protocol._
10. The request MAY include a header with the name "Sec-WebSocket- 10. The request MAY include a header with the name "Sec-WebSocket-
Protocol". If present, this value indicates the subprotocol(s) Protocol". If present, this value indicates one or more comma
the client wishes to speak, ordered by preference. The elements separated subprotocol the client wishes to speak, ordered by
that comprise this value MUST be non-empty strings with preference. The elements that comprise this value MUST be non-
characters in the range U+0021 to U+007E not including separator empty strings with characters in the range U+0021 to U+007E not
characters as defined in [RFC2616], and MUST all be unique including separator characters as defined in [RFC2616], and MUST
strings. The ABNF for the value of this header is 1#token, all be unique strings. The ABNF for the value of this header is
where the definitions of constructs and rules are as given in 1#token, where the definitions of constructs and rules are as
[RFC2616]. given in [RFC2616].
11. The request MAY include a header with the name "Sec-WebSocket- 11. The request MAY include a header with the name "Sec-WebSocket-
Extensions". If present, this value indicates the protocol- Extensions". If present, this value indicates the protocol-
level extension(s) the client wishes to speak. The level extension(s) the client wishes to speak. The
interpretation and format of this header is described in interpretation and format of this header is described in
Section 9.1. Section 9.1.
12. The request MAY include headers associated with sending cookies, 12. The request MAY include headers associated with sending cookies,
as defined by the appropriate specifications as defined by the appropriate specifications [RFC6265]. These
[I-D.ietf-httpstate-cookie]. These headers are referred to as headers are referred to as _Headers to Send Appropriate
_Headers to Send Appropriate Cookies_. Cookies_.
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 procedures. Otherwise,
proceed as follows. proceed as follows.
2. If the response lacks an "Upgrade" header or the "Upgrade" header 2. If the response lacks an "Upgrade" header or the "Upgrade" header
skipping to change at page 31, line 51 skipping to change at page 32, line 4
3. If the response lacks a "Connection" header or the "Connection" 3. If the response lacks a "Connection" header or the "Connection"
header contains a value that is not an ASCII case-insensitive header contains a value that is not an ASCII case-insensitive
match for the value "Upgrade", the client MUST _Fail the match for the value "Upgrade", the client MUST _Fail the
WebSocket Connection_. WebSocket Connection_.
4. If the response lacks a "Sec-WebSocket-Accept" header or the 4. If the response lacks a "Sec-WebSocket-Accept" header or the
"Sec-WebSocket-Accept" contains a value other than the base64- "Sec-WebSocket-Accept" contains a value other than the base64-
encoded SHA-1 of the concatenation of the "Sec-WebSocket-Key" (as encoded SHA-1 of the concatenation of the "Sec-WebSocket-Key" (as
a string, not base64-decoded) with the string "258EAFA5-E914- a string, not base64-decoded) with the string "258EAFA5-E914-
47DA-95CA-C5AB0DC85B11", the client MUST _Fail the WebSocket 47DA-95CA-C5AB0DC85B11", but ignoring any leading and trailing
Connection_ whitespace, the client MUST _Fail the WebSocket Connection_
5. If the response includes a "Sec-WebSocket-Extensions" header, and 5. If the response includes a "Sec-WebSocket-Extensions" header, and
this header indicates the use of an extension that was not this header indicates the use of an extension that was not
present in the client' handshake (the server has indicated an present in the client' handshake (the server has indicated an
extension not requested by the client), the client MUST _Fail the extension not requested by the client), the client MUST _Fail the
WebSocket Connection_. (The parsing of this header to determine WebSocket Connection_. (The parsing of this header to determine
which extensions are requested is discussed in Section 9.1.) which extensions are requested is discussed in Section 9.1.)
If the server's response does not conform to the requirements for the
server's handshake as defined in this section and in Section 5.2.2,
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 supplied equal to the value of the |Sec-WebSocket-Extensions| header supplied
by the server's handshake, or the null value if that header was not by the server's handshake, or the null value if that header was not
present in the server's handshake. The _Subprotocol In Use_ is present in the server's handshake. The _Subprotocol In Use_ is
defined to be the value of the |Sec-WebSocket-Protocol| header in the defined to be the value of the |Sec-WebSocket-Protocol| header in the
server's handshake, or the null value if that header was not present server's handshake, or the null value if that header was not present
in the server's handshake. Additionally, if any headers in the in the server's handshake. Additionally, if any headers in the
server's handshake indicate that cookies should be set (as defined by server's handshake indicate that cookies should be set (as defined by
[I-D.ietf-httpstate-cookie]), these cookies are referred to as [RFC6265]), these cookies are referred to as _Cookies Set During the
_Cookies Set During the Server's Opening Handshake_. Server's Opening Handshake_.
5.2. Server-side Requirements 5.2. Server-side Requirements
_This section only applies to servers._ _This section only applies to servers._
Servers MAY offload the management of the connection to other agents Servers MAY offload the management of the connection to other agents
on the network, for example load balancers and reverse proxies. In on the network, for example load balancers and reverse proxies. In
such a situation, the server for the purposes of conformance is such a situation, the server for the purposes of conformance is
considered to include all parts of the server-side infrastructure considered to include all parts of the server-side infrastructure
from the first device to terminate the TCP connection all the way to from the first device to terminate the TCP connection all the way to
skipping to change at page 32, line 52 skipping to change at page 33, line 14
5.2.1. Reading the Client's Opening Handshake 5.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, the server not send a handshake that matches the description below, including
MUST stop processing the client's handshake, and return an HTTP but not limited to any violations of the grammar (ABNF) specified for
response with an appropriate error code (such as 400 Bad Request). the components of the handshake, the server MUST stop 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. Section 3.
2. A "Host" header containing the server's authority. 2. A "Host" header containing the server's authority.
3. A "Sec-WebSocket-Key" header with a base64-encoded value that, 3. A "Sec-WebSocket-Key" header with a base64-encoded (see Section 4
when decoded, is 16 bytes in length. of [RFC4648]) value that, when decoded, is 16 bytes in length.
4. A "Sec-WebSocket-Version" header, with a value of 8. 4. A "Sec-WebSocket-Version" header, with a value of 8.
5. Optionally, a "Sec-WebSocket-Origin" header. This header is sent 5. Optionally, a "Sec-WebSocket-Origin" header. This header is sent
by all browser clients. A connection attempt lacking this header by all browser clients. A connection attempt lacking this header
SHOULD NOT be interpreted as coming from a browser client. SHOULD NOT be interpreted as coming from a browser client.
6. Optionally, a "Sec-WebSocket-Protocol" header, with a list of 6. Optionally, a "Sec-WebSocket-Protocol" header, with a list of
values indicating which protocols the client would like to speak, values indicating which protocols the client would like to speak,
ordered by preference. ordered by preference.
skipping to change at page 34, line 47 skipping to change at page 35, line 8
/resource name/ /resource name/
An identifier for the service provided by the server. If the An identifier for the service provided by the server. If the
server provides multiple services, then the value should be server provides multiple services, then the value should be
derived from the resource name given in the client's handshake derived from the resource name given in the client's handshake
from the Request-URI [RFC2616] of the GET method. If the from the Request-URI [RFC2616] of the GET method. If the
requested service is not available, the server MUST send an requested service is not available, the server MUST send an
appropriate HTTP error code (such as 404 Not Found) and abort appropriate HTTP error code (such as 404 Not Found) and abort
the WebSocket handshake. the WebSocket handshake.
/subprotocol/ /subprotocol/
Either a single value or null, representing the subprotocol Either a single value representing the subprotocol the server
the server is ready to use. If the server supports multiple is ready to use or null. The value chosen MUST be derived
subprotocols, then the value MUST be derived from the client's from the client's handshake, specifically by selecting one of
handshake, specifically by selecting one of the values from the values from the "Sec-WebSocket-Protocol" field that the
the "Sec-WebSocket-Protocol" field. The absence of such a server is willing to use for this connection (if any). If the
field is equivalent to the null value. The empty string is client's handshake did not contain such a header, or if the
not the same as the null value for these purposes, and is not server does not agree to any of the client's requested
a legal value for this field. The ABNF for the value of this subprotocols, the only acceptable value is null. The absence
header is (token), where the definitions of constructs and of such a field is equivalent to the null value (meaning that
rules are as given in [RFC2616]. if the server does not wish to agree to one of the suggested
subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol|
header in its response). The empty string is not the same as
the null value for these purposes, and is not a legal value
for this field. The ABNF for the value of this header is
(token), where the definitions of constructs and rules are as
given in [RFC2616].
/extensions/ /extensions/
A (possibly empty) list representing the protocol-level A (possibly empty) list representing the protocol-level
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
skipping to change at page 35, line 38 skipping to change at page 36, line 6
2. An "Upgrade" header with value "websocket" as per RFC 2616 2. An "Upgrade" header with value "websocket" as per RFC 2616
[RFC2616]. [RFC2616].
3. A "Connection" header with value "Upgrade" 3. A "Connection" header with value "Upgrade"
4. A "Sec-WebSocket-Accept" header. The value of this header is 4. A "Sec-WebSocket-Accept" header. The value of this header is
constructed by concatenating /key/, defined above in constructed by concatenating /key/, defined above in
Paragraph 2 of Section 5.2.2, with the string "258EAFA5-E914- Paragraph 2 of Section 5.2.2, with the string "258EAFA5-E914-
47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this 47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this
concatenated value to obtain a 20-byte value, and base64- concatenated value to obtain a 20-byte value, and base64-
encoding this 20-byte hash. encoding (see Section 4 of [RFC4648]) this 20-byte hash.
The ABNF of this header is defined as follows: The ABNF of this header is defined as follows:
accept-value = base64-value accept-value = 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 "==") / (3base64-character "=")
base64-character = ALPHA / DIGIT / "+" / "/" base64-character = ALPHA / DIGIT / "+" / "/"
NOTE: As an example, if the value of the "Sec-WebSocket-Key" NOTE: As an example, if the value of the "Sec-WebSocket-Key"
skipping to change at page 38, line 20 skipping to change at page 38, line 20
type /type/ (noted from the first frame of the fragmented message). type /type/ (noted from the first frame of the fragmented message).
Subsequent data frames MUST be interpreted as belonging to a new Subsequent data frames MUST be interpreted as belonging to a new
WebSocket Message. WebSocket Message.
Extensions (Section 9) MAY change the semantics of how data is read, Extensions (Section 9) MAY change the semantics of how data is read,
specifically including what comprises a message boundary. specifically including what comprises a message boundary.
Extensions, in addition to adding "Extension data" before the Extensions, in addition to adding "Extension data" before the
"Application data" in a payload, MAY also modify the "Application "Application data" in a payload, MAY also modify the "Application
data" (such as by compressing it). data" (such as by compressing it).
Data frames received by a server from a client MUST be unmasked as A server MUST remove masking for data frames received from a client
described in Section 4.3. as described in Section 4.3.
7. Closing the connection 7. Closing the connection
7.1. Definitions 7.1. Definitions
7.1.1. Close the WebSocket Connection 7.1.1. Close the WebSocket Connection
To _Close the WebSocket Connection_, an endpoint closes the To _Close the WebSocket Connection_, an endpoint closes the
underlying TCP connection. An endpoint SHOULD use a method that underlying TCP connection. An endpoint SHOULD use a method that
cleanly closes the TCP connection, as well as the TLS session, if cleanly closes the TCP connection, as well as the TLS session, if
skipping to change at page 43, line 32 skipping to change at page 43, line 32
code was actually present. code was actually present.
1006 1006
1006 is a reserved value and MUST NOT be set as a status code in a 1006 is a reserved value and MUST NOT be set as a status code in a
Close control frame by an endpoint. It is designated for use in Close control frame by an endpoint. It is designated for use in
applications expecting a status code to indicate that the applications expecting a status code to indicate that the
connection was closed abnormally, e.g. without sending or connection was closed abnormally, e.g. without sending or
receiving a Close control frame. receiving a Close control frame.
1007
1007 indicates that an endpoint is terminating the connection
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].
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-1999 1000-1999
Status codes in the range 1000-1999 are reserved for definition by Status codes in the range 1000-1999 are reserved for definition by
this protocol. this protocol.
skipping to change at page 45, line 7 skipping to change at page 45, line 7
range. range.
4000-4999 4000-4999
Status codes in the range 4000-4999 MAY be used by application Status codes in the range 4000-4999 MAY be used by application
code. The interpretation of these codes is undefined by this code. The interpretation of these codes is undefined by this
protocol. protocol.
8. Error Handling 8. Error Handling
8.1. Handling Errors in UTF-8 from the Server 8.1. Handling Errors in UTF-8 Encoded Data
When a client is to interpret a byte stream as UTF-8 but finds that
the byte stream is not in fact a valid UTF-8 stream, then any bytes
or sequences of bytes that are not valid UTF-8 sequences MUST be
interpreted as a U+FFFD REPLACEMENT CHARACTER.
8.2. Handling Errors in UTF-8 from the Client
When a server is to interpret a byte stream as UTF-8 but finds that When an endpoint is to interpret a byte stream as UTF-8 but finds
the byte stream is not in fact a valid UTF-8 stream, behavior is that the byte stream is not in fact a valid UTF-8 stream, that
undefined. A server could close the connection, convert invalid byte endpoint MUST _Fail the WebSocket Connection_.
sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim,
or perform application-specific processing. Subprotocols layered on
the WebSocket protocol might define specific behavior for servers.
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.
skipping to change at page 46, line 43 skipping to change at page 46, line 43
Note that like other HTTP headers, this header MAY be split or Note that like other HTTP headers, this header MAY be split or
combined across multiple lines. Ergo, the following are equivalent: combined across multiple lines. Ergo, the following are 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 Any extension-token used MUST either be a registered token (see
(registration TBD), or have a prefix of "x-" to indicate a private- Section 11.6), or have a prefix of "x-" to indicate a private-use
use token. The parameters supplied with any given extension MUST be token. The parameters supplied with any given extension MUST be
defined for that extension. Note that the client is only offering to defined for that extension. Note that the client is only offering 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 headers listed by the client in its interpretation is that the headers listed by the client in its
request represent a preference of the headers it wishes to use, with request represent a preference of the headers it wishes to use, with
the first options listed being most preferable. The extensions the first options listed being most preferable. The extensions
skipping to change at page 50, line 16 skipping to change at page 50, line 16
browser to send a frame that looks to an intermediary like a GET 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 request for a common piece of JavaScript on another domain, and send
back a frame that is interpreted as a cacheable response to that back a frame that is interpreted as a cacheable response to that
request, thus poisioning the cache for other users. To prevent this 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 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 value, to prevent an attacker from controlling the bits on the wire
and thus lessen the probability of an attacker being able to and thus lessen the probability of an attacker being able to
construct a frame that can be misinterpreted by a proxy as a non- construct a frame that can be misinterpreted by a proxy as a non-
WebSocket request. WebSocket request.
As mentioned in Section 8.2, servers must be extremely cautious
interpreting invalid UTF-8 data from the client. A naive UTF-8
parsing implementation can result in buffer overflows in the case of
invalid input data.
For connections using TLS (wss: URIs), the amount of benefit provided For connections using TLS (wss: URIs), the amount of benefit provided
by TLS depends greatly on the strength of the algorithms negotiated by TLS depends greatly on the strength of the algorithms negotiated
during the TLS handshake. To achieve reasonable levels of during the TLS handshake. To achieve reasonable levels of
protections, clients should use only Strong TLS algorithms. "Web protections, clients should use only Strong TLS algorithms. "Web
Security Context: User Interface Guidelines" Security Context: User Interface Guidelines"
[W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS [W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS
algorithms. algorithms.
11. IANA Considerations 11. IANA Considerations
skipping to change at page 51, line 48 skipping to change at page 51, line 48
Characters in other components that are excluded by the syntax Characters in other components that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by first defined above MUST be converted from Unicode to ASCII by first
encoding the characters as UTF-8 and then replacing the encoding the characters as UTF-8 and then replacing the
corresponding bytes using their percent-encoded form as defined in corresponding bytes using their percent-encoded form as defined in
the URI and IRI specifications. [RFC3986] [RFC3987] the URI and IRI specifications. [RFC3986] [RFC3987]
Applications/protocols that use this URI scheme name. Applications/protocols that use this URI scheme name.
WebSocket protocol. WebSocket protocol.
Interoperability considerations. Interoperability considerations.
None. Use of WebSocket requires use of HTTP version 1.1 or higher.
Security considerations. Security considerations.
See "Security considerations" section above. See "Security considerations" section above.
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>
skipping to change at page 53, line 12 skipping to change at page 53, line 12
Characters in other components that are excluded by the syntax Characters in other components that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by first defined above MUST be converted from Unicode to ASCII by first
encoding the characters as UTF-8 and then replacing the encoding the characters as UTF-8 and then replacing the
corresponding bytes using their percent-encoded form as defined in corresponding bytes using their percent-encoded form as defined in
the URI and IRI specification. [RFC3986] [RFC3987] the URI and IRI specification. [RFC3986] [RFC3987]
Applications/protocols that use this URI scheme name. Applications/protocols that use this URI scheme name.
WebSocket protocol over TLS. WebSocket protocol over TLS.
Interoperability considerations. Interoperability considerations.
None. Use of WebSocket requires use of HTTP version 1.1 or higher.
Security considerations. Security considerations.
See "Security considerations" section above. See "Security considerations" section above.
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>
skipping to change at page 55, line 41 skipping to change at page 55, line 41
to. to.
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 Serve WebSocket Extension names are to be subject to "First Come First
as per RFC5226 [RFC5226], with the exception of WebSocket Extension Served" IANA registration policy [RFC5226], with the exception of
names whose Extension Identifier matches a private-use-token as WebSocket Extension names whose Extension Identifier matches a
defined in Section 9.1 (values beginning with "x-"). These Extension private-use-token as defined in Section 9.1 (values beginning with
Identifiers matching private-use-token are reserved for Experimental "x-"). These Extension Identifiers matching private-use-token are
Use as per RFC5226 [RFC5226]. reserved for Experimental Use as per RFC5226 [RFC5226].
IANA is asked to add an initial value to the registry (there are no IANA is asked to add an initial value to the registry (there are no
known incompatible extensions for this initial entry): known incompatible extensions for this initial entry):
Extension Identifier | Extension Common Name | Extension Definition Extension Identifier | Extension Common Name | Extension Definition
-+---------------------+------------------------+----------------------- -+---------------------+------------------------+-----------------------
| deflate-stream | Deflate Stream | Section 9.2.1 of this | deflate-stream | Deflate Stream | Section 9.2.1 of this
| | Compression | document. | | Compression | document.
-+---------------------+------------------------+----------------------- -+---------------------+------------------------+-----------------------
skipping to change at page 58, line 13 skipping to change at page 58, line 13
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
information: information:
Subprotocol Identifier Subprotocol Identifier
The identifier of the subprotocol, as will be used in the Sec- The identifier of the subprotocol, as will be used in the Sec-
WebSocket-Protocol header registered in Section 11.9 of this WebSocket-Protocol header registered in Section 11.9 of this
specification. The value must conform to the requirements given specification. The value must conform to the requirements given
in Paragraph 10 of Paragraph 4 of Section 5.1 of this in Paragraph 10 of Section 5.1 of this specification, namely the
specification, namely the value must be a token as defined by RFC value must be a token as defined by RFC 2616 [RFC2616].
2616 [RFC2616].
Subprotocol Common Name Subprotocol Common Name
The name of the subprotocol, as the subprotocol is generally The name of the subprotocol, as the subprotocol is generally
referred to. referred to.
Subprotocol Definition Subprotocol Definition
A reference to the document in which the subprotocol being used A reference to the document in which the subprotocol being used
with the WebSocket protocol is defined. with the WebSocket protocol is defined.
WebSocket Subprotocol names are to be subject to First Come First WebSocket Subprotocol names are to be subject to "First Come First
Serve as per RFC5226 [RFC5226]. Served" IANA registration policy [RFC5226].
11.11. Sec-WebSocket-Version 11.11. Sec-WebSocket-Version
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Version Sec-WebSocket-Version
Applicable protocol Applicable protocol
skipping to change at page 59, line 27 skipping to change at page 59, line 26
information: information:
Version Number Version Number
The version number to be used in the Sec-WebSocket-Version as The version number to be used in the Sec-WebSocket-Version as
specified in Section 5.1 of this specification. The value must be specified in Section 5.1 of this specification. The value must be
a whole number (zero or higher). a whole number (zero or higher).
Reference Reference
The RFC requesting a new version number. The RFC requesting a new version number.
WebSocket Version Numbers are to be subject to RFC Required as per WebSocket Version Numbers are to be subject to "IETF Review" IANA
RFC5226 [RFC5226]. registration policy [RFC5226]. In order to improve interoperability
with intermediate versions published in Internet Drafts, version
numbers associated with such drafts might be registered in this
registry.
IANA is asked to add initial values to the registry, with suggested IANA is asked to add initial values to the registry, with suggested
numerical values as these have been used in past versions of this numerical values as these have been used in past versions of this
protocol. protocol.
Version Number | Reference Version Number | Reference
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 0 + draft-ietf-hybi-thewebsocketprotocol-00 | | 0 + draft-ietf-hybi-thewebsocketprotocol-00 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 1 + draft-ietf-hybi-thewebsocketprotocol-01 | | 1 + draft-ietf-hybi-thewebsocketprotocol-01 |
skipping to change at page 61, line 5 skipping to change at page 61, line 5
Contact Contact
A contact for the entity reserving the status code. A contact for the entity reserving the status code.
Reference Reference
The stable document requesting the status codes and defining their The stable document requesting the status codes and defining their
meaning, required for status codes in the range 1000-2999. meaning, required for status codes in the range 1000-2999.
WebSocket Close Code Numbers are to be subject to different WebSocket Close Code Numbers are to be subject to different
registration requirements depending on their range. Unless otherwise registration requirements depending on their range. Unless otherwise
specified, requests are subject to Standards Action as per RFC5226 specified, requests are subject to "Standards Action" IANA
[RFC5226]. Requests for status codes for use by this protocol or registration policy [RFC5226]. Requests for status codes for use by
subsequent versions are subject to Standards Action and should be this protocol or subsequent versions are subject to Standards Action
granted status codes in the range 1000-1999. Requests for status and should be granted status codes in the range 1000-1999. Requests
codes for use by extensions are subject to Specification Required and for status codes for use by extensions are subject to Specification
should be granted Status Codes in the range 2000-2999. Requests for Required and should be granted Status Codes in the range 2000-2999.
status codes for use by libraries and frameworks are subject to First Requests for status codes for use by libraries and frameworks are
Come First Served and should be granted in the range 3000-3999. The subject to First Come First Served and should be granted in the range
range of status codes from 4000-4999 is designated for Private Use by 3000-3999. The range of status codes from 4000-4999 is designated
application code. Requests should indicate whether they are for Private Use by application code. Requests should indicate
requesting status codes for use by the WebSocket protocol (or a whether they are requesting status codes for use by the WebSocket
future version of the protocol), by extensions, or by libraries and protocol (or a future version of the protocol), by extensions, or by
frameworks. libraries and frameworks.
IANA is asked to add initial values to the registry, with suggested IANA is asked to add initial values to the registry, with suggested
numerical values as these have been used in past versions of this numerical values as these have been used in past versions of this
protocol. protocol.
|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 |
skipping to change at page 61, line 39 skipping to change at page 61, line 39
| 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 | Frame Too Large | 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 |
-+------------+-----------------+---------------+-----------|
11.14. WebSocket Opcode Registry 11.14. 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 62, line 16 skipping to change at page 62, line 16
The opcode denotes the frame type of the WebSocket frame, as The opcode denotes the frame type of the WebSocket frame, as
defined in Section 4.2. The status code is an integer number defined in Section 4.2. The status code is an integer number
between 0 and 15, inclusive. between 0 and 15, inclusive.
Meaning Meaning
The meaning of the opcode code. The meaning of the opcode code.
Reference Reference
The specification requesting the opcode. The specification requesting the opcode.
WebSocket Opcode numbers are subject to Standards Action as per WebSocket Opcode numbers are subject to "Standards Action" IANA
RFC5226 [RFC5226]. registration policy [RFC5226].
IANA is asked to add initial values to the registry, with suggested IANA is asked to add initial values to the registry, with suggested
numerical values as these have been used in past versions of this numerical values as these have been used in past versions of this
protocol. protocol.
|Opcode | Meaning | Reference | |Opcode | Meaning | Reference |
-+--------+-------------------------------------+-----------| -+--------+-------------------------------------+-----------|
| 0 | Continuation Frame | RFC XXXX | | 0 | Continuation Frame | RFC XXXX |
-+--------+-------------------------------------+-----------| -+--------+-------------------------------------+-----------|
| 1 | Text Frame | RFC XXXX | | 1 | Text Frame | RFC XXXX |
skipping to change at page 62, line 48 skipping to change at page 62, line 48
11.15. WebSocket Framing Header Bits Registry 11.15. WebSocket Framing Header Bits Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Framing Header Bits in accordance with the principles set WebSocket Framing Header Bits in accordance with the principles set
out in RFC 5226 [RFC5226]. This registry controls assignment of the out in RFC 5226 [RFC5226]. This registry controls assignment of the
bits marked RSV1, RSV2, and RSV3 in Section 4.2. bits marked RSV1, RSV2, and RSV3 in Section 4.2.
These bits are reserved for future versions or extensions of this These bits are reserved for future versions or extensions of this
specification. specification.
WebSocket Framing Header Bits assignments are subject to Standards WebSocket Framing Header Bits assignments are subject to "Standards
Action per RFC 5226 [RFC5226]. Action" IANA registration policy [RFC5226].
12. Using the WebSocket protocol from Other Specifications 12. Using the WebSocket protocol from Other Specifications
The WebSocket protocol is intended to be used by another The WebSocket protocol is intended to be used by another
specification to provide a generic mechanism for dynamic author- specification to provide a generic mechanism for dynamic author-
defined content, e.g. in a specification defining a scripted API. defined content, e.g. in a specification defining a scripted API.
Such a specification first needs to _Establish a WebSocket Such a specification first needs to _Establish a WebSocket
Connection_, providing that algorithm with: Connection_, providing that algorithm with:
skipping to change at page 65, line 19 skipping to change at page 65, line 19
[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.
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
skipping to change at page 66, line 25 skipping to change at page 66, line 27
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[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]
Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-00 (work in progress),
December 2010.
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/>.
[I-D.ietf-httpstate-cookie] [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
Barth, A., "HTTP State Management Mechanism", April 2011.
draft-ietf-httpstate-cookie-20 (work in progress),
December 2010.
[I-D.ietf-websec-origin]
Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-00 (work in progress),
December 2010.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long "Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202, Polling and Streaming in Bidirectional HTTP", RFC 6202,
April 2011. April 2011.
[W3C.REC-wsc-ui-20100812] [W3C.REC-wsc-ui-20100812]
Saldhana, A. and T. Roessler, "Web Security Context: User Roessler, T. and A. Saldhana, "Web Security Context: User
Interface Guidelines", World Wide Web Consortium Interface Guidelines", World Wide Web Consortium
Recommendation REC-wsc-ui-20100812, August 2010, Recommendation REC-wsc-ui-20100812, August 2010,
<http://www.w3.org/TR/2010/REC-wsc-ui-20100812>. <http://www.w3.org/TR/2010/REC-wsc-ui-20100812>.
Author's Address Authors' Addresses
Ian Fette Ian Fette
Google, Inc. Google, Inc.
Email: ifette+ietf@google.com Email: ifette+ietf@google.com
URI: http://www.ianfette.com/ URI: http://www.ianfette.com/
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
Email: Alexey.Melnikov@isode.com
 End of changes. 66 change blocks. 
200 lines changed or deleted 215 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/