draft-ietf-hybi-thewebsocketprotocol-14.txt   draft-ietf-hybi-thewebsocketprotocol-15.txt 
HyBi Working Group I. Fette HyBi Working Group I. Fette
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Melnikov
Expires: March 11, 2012 Isode Ltd Expires: March 20, 2012 Isode Ltd
September 8, 2011 September 17, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-14 draft-ietf-hybi-thewebsocketprotocol-15
Abstract Abstract
The WebSocket protocol enables two-way communication between a client The WebSocket protocol enables two-way communication between a client
running untrusted code running in a controlled environment to a running untrusted code running in a controlled environment to a
remote host that has opted-in to communications from that code. The remote host that has opted-in to communications from that code. The
security model used for this is the Origin-based security model security model used for this is the Origin-based security model
commonly used by Web browsers. The protocol consists of an opening commonly used by Web browsers. The protocol consists of an opening
handshake followed by basic message framing, layered over TCP. The handshake followed by basic message framing, layered over TCP. The
goal of this technology is to provide a mechanism for browser-based goal of this technology is to provide a mechanism for browser-based
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2012. This Internet-Draft will expire on March 20, 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 26 skipping to change at page 2, line 26
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 7 1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 7
1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 10 1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 10
1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 10 1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 10
1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 11 1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 11
1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 12 1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 12
1.8. Establishing a Connection . . . . . . . . . . . . . . . . 12 1.8. Establishing a Connection . . . . . . . . . . . . . . . . 12
1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 12 1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 12
2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 14 2.1. Terminology and other conventions . . . . . . . . . . . . 14
3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 16 3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 17 4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Client Requirements . . . . . . . . . . . . . . . . . . . 17 4.1. Client Requirements . . . . . . . . . . . . . . . . . . . 17
4.2. Server-side Requirements . . . . . . . . . . . . . . . . . 22 4.2. Server-side Requirements . . . . . . . . . . . . . . . . . 22
4.2.1. Reading the Client's Opening Handshake . . . . . . . . 23 4.2.1. Reading the Client's Opening Handshake . . . . . . . . 23
4.2.2. Sending the Server's Opening Handshake . . . . . . . . 24 4.2.2. Sending the Server's Opening Handshake . . . . . . . . 24
4.3. Collected ABNF for new header fields used in handshake . . 27 4.3. Collected ABNF for new header fields used in handshake . . 27
4.4. Supporting multiple versions of WebSocket protocol . . . . 28 4.4. Supporting multiple versions of WebSocket protocol . . . . 28
5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 30 5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 30 5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 30
5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 34 5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 34
5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 35 5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 35
5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 37 5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 37
5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 37 5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 39 5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 39
5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 40 5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 41
6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 42 6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 42
6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 42 6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 42
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 44 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 44
7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 44 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 44 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 44
7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 44 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 44
7.1.3. The WebSocket Closing Handshake is Started . . . . . . 44 7.1.3. The WebSocket Closing Handshake is Started . . . . . . 44
7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 45 7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 45
7.1.5. The WebSocket Connection Close Code . . . . . . . . . 45 7.1.5. The WebSocket Connection Close Code . . . . . . . . . 45
skipping to change at page 3, line 33 skipping to change at page 3, line 33
9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 52 9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 52
9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 53 9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 53
10. Security Considerations . . . . . . . . . . . . . . . . . . . 54 10. Security Considerations . . . . . . . . . . . . . . . . . . . 54
10.1. Non-Browser Clients . . . . . . . . . . . . . . . . . . . 54 10.1. Non-Browser Clients . . . . . . . . . . . . . . . . . . . 54
10.2. Origin Considerations . . . . . . . . . . . . . . . . . . 54 10.2. Origin Considerations . . . . . . . . . . . . . . . . . . 54
10.3. Attacks On Infrastructure (Masking) . . . . . . . . . . . 55 10.3. Attacks On Infrastructure (Masking) . . . . . . . . . . . 55
10.4. Implementation-Specific Limits . . . . . . . . . . . . . . 56 10.4. Implementation-Specific Limits . . . . . . . . . . . . . . 56
10.5. WebSocket client authentication . . . . . . . . . . . . . 56 10.5. WebSocket client authentication . . . . . . . . . . . . . 56
10.6. Connection confidentiality and integrity . . . . . . . . . 57 10.6. Connection confidentiality and integrity . . . . . . . . . 57
10.7. Handling of invalid data . . . . . . . . . . . . . . . . . 57 10.7. Handling of invalid data . . . . . . . . . . . . . . . . . 57
10.8. Use of SHA-1 by the WebSocket protocol . . . . . . . . . . 57 10.8. Use of SHA-1 by the WebSocket handshake . . . . . . . . . 57
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
11.1. Registration of new URI Schemes . . . . . . . . . . . . . 59 11.1. Registration of new URI Schemes . . . . . . . . . . . . . 59
11.1.1. Registration of "ws" Scheme . . . . . . . . . . . . . 59 11.1.1. Registration of "ws" Scheme . . . . . . . . . . . . . 59
11.1.2. Registration of "wss" Scheme . . . . . . . . . . . . . 60 11.1.2. Registration of "wss" Scheme . . . . . . . . . . . . . 60
11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 61 11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 61
11.3. Registration of new HTTP Header Fields . . . . . . . . . . 61 11.3. Registration of new HTTP Header Fields . . . . . . . . . . 61
11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 61 11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 62
11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 62 11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 62
11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 63 11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 63
11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 64 11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 64
11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 64 11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 64
11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 65 11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 65
11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 66 11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 66
11.6. WebSocket Version Number Registry . . . . . . . . . . . . 66 11.6. WebSocket Version Number Registry . . . . . . . . . . . . 67
11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 68 11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 68
11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 70 11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 70
11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 71 11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 71
12. Using the WebSocket protocol from Other Specifications . . . . 72 12. Using the WebSocket protocol from Other Specifications . . . . 72
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 73
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.1. Normative References . . . . . . . . . . . . . . . . . . . 74 14.1. Normative References . . . . . . . . . . . . . . . . . . . 74
14.2. Informative References . . . . . . . . . . . . . . . . . . 75 14.2. Informative References . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
skipping to change at page 8, line 31 skipping to change at page 8, line 31
request. If the server does not wish to accept connections from this request. If the server does not wish to accept connections from this
origin, it can choose to reject the connection by sending an origin, it can choose to reject the connection by sending an
appropriate HTTP error code. This header field is sent by browser appropriate HTTP error code. This header field is sent by browser
clients, for non-browser clients this header field may be sent if it clients, for non-browser clients this header field may be sent if it
makes sense in the context of those clients. makes sense in the context of those clients.
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| [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 field piece of information comes from the |Sec-WebSocket-Key| header field
in the client handshake: in the client handshake:
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
For this header field, the server has to take the value (as present For this header field, the server has to take the value (as present
in the header field, e.g. the base64-encoded [RFC4648] version minus in the header field, e.g. the base64-encoded [RFC4648] version minus
skipping to change at page 12, line 15 skipping to change at page 12, line 15
It is similarly intended to fail to establish a connection when data It is similarly intended to fail to establish a connection when data
from other protocols, especially HTTP, is sent to a WebSocket server, from other protocols, especially HTTP, is sent to a WebSocket server,
for example as might happen if an HTML |form| were submitted to a for example as might happen if an HTML |form| were submitted to a
WebSocket server. This is primarily achieved by requiring that the WebSocket server. This is primarily achieved by requiring that the
server prove that it read the handshake, which it can only do if the server prove that it read the handshake, which it can only do if the
handshake contains the appropriate parts which themselves can only be handshake contains the appropriate parts which themselves can only be
sent by a WebSocket handshake. In particular, at the time of writing sent by a WebSocket handshake. In particular, at the time of writing
of this specification, fields starting with |Sec-| cannot be set by of this specification, fields starting with |Sec-| cannot be set by
an attacker from a Web browser using only HTML and JavaScript APIs an attacker from a Web browser using only HTML and JavaScript APIs
such as |XMLHttpRequest|. such as |XMLHttpRequest| [XMLHttpRequest].
1.7. Relationship to TCP and HTTP 1.7. Relationship to TCP and HTTP
_This section is non-normative._ _This section is non-normative._
The WebSocket protocol is an independent TCP-based protocol. Its The WebSocket protocol is an independent TCP-based protocol. Its
only relationship to HTTP is that its handshake is interpreted by only relationship to HTTP is that its handshake is interpreted by
HTTP servers as an Upgrade request. HTTP servers as an Upgrade request.
By default the WebSocket protocol uses port 80 for regular WebSocket By default the WebSocket protocol uses port 80 for regular WebSocket
skipping to change at page 14, line 26 skipping to change at page 14, line 26
"strip any leading space characters" or "return false and abort these "strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word steps") are to be interpreted with the meaning of the key word
("must", "should", "may", etc) used in introducing the algorithm. ("must", "should", "may", etc) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps MAY Conformance requirements phrased as algorithms or specific steps MAY
be implemented in any manner, so long as the end result is be implemented in any manner, so long as the end result is
equivalent. (In particular, the algorithms defined in this equivalent. (In particular, the algorithms defined in this
specification are intended to be easy to follow, and not intended to specification are intended to be easy to follow, and not intended to
be performant.) be performant.)
2.1. Terminology 2.1. Terminology and other conventions
_ASCII_ shall mean the character-encoding scheme defined in _ASCII_ shall mean the character-encoding scheme defined in
[ANSI.X3-4.1986]. [ANSI.X3-4.1986].
This document makes reference to UTF-8 values and uses UTF-8 This document makes reference to UTF-8 values and uses UTF-8
notational formats as defined in STD 63 [RFC3629]. notational formats as defined in STD 63 [RFC3629].
Key Terms such as named algorithms or definitions are indicated like Key Terms such as named algorithms or definitions are indicated like
_this_. _this_.
skipping to change at page 16, line 5 skipping to change at page 15, line 15
range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL
LETTER Z) are considered to also match. LETTER Z) are considered to also match.
The term "URI" is used in this document as defined in [RFC3986]. The term "URI" is used in this document as defined in [RFC3986].
When an implementation is required to _send_ data as part of the When an implementation is required to _send_ data as part of the
WebSocket protocol, the implementation MAY delay the actual WebSocket protocol, the implementation MAY delay the actual
transmission arbitrarily, e.g. buffering data so as to send fewer IP transmission arbitrarily, e.g. buffering data so as to send fewer IP
packets. packets.
Note that this document uses both [RFC5234] and [RFC2616] variants of
ABNF in different sections.
3. WebSocket URIs 3. WebSocket URIs
This specification defines two URI schemes, using the ABNF syntax This specification defines two URI schemes, using the ABNF syntax
defined in RFC 5234 [RFC5234], and terminology and ABNF productions defined in RFC 5234 [RFC5234], and terminology and ABNF productions
defined by the URI specification RFC 3986 [RFC3986]. defined by the URI specification RFC 3986 [RFC3986].
ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
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>
skipping to change at page 23, line 22 skipping to change at page 23, line 22
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 (note that as not send a handshake that matches the description below (note that as
per [RFC2616] the order of the header fields is not important), per [RFC2616] the order of the header fields is not important),
including but not limited to any violations of the grammar (ABNF) including but not limited to any violations of the ABNF grammar
specified for the components of the handshake, the server MUST stop specified for the components of the handshake, the server MUST stop
processing the client's handshake, and return an HTTP response with processing the client's handshake, and return an HTTP response with
an appropriate error code (such as 400 Bad Request). an appropriate error code (such as 400 Bad Request).
1. An HTTP/1.1 or higher GET request, including a "Request-URI" 1. An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/ [RFC2616] that should be interpreted as a /resource name/
Section 3 (or an absolute HTTP/HTTPS URI containing the Section 3 (or an absolute HTTP/HTTPS URI containing the
/resource name/). /resource name/).
2. A "Host" header field containing the server's authority. 2. A "Host" header field containing the server's authority.
skipping to change at page 26, line 37 skipping to change at page 26, line 37
3. A "Connection" header field with value "Upgrade" 3. A "Connection" header field with value "Upgrade"
4. A "Sec-WebSocket-Accept" header field. The value of this 4. A "Sec-WebSocket-Accept" header field. The value of this
header field is constructed by concatenating /key/, defined header field is constructed by concatenating /key/, defined
above in Paragraph 4 of Section 4.2.2, with the string above in Paragraph 4 of Section 4.2.2, with the string
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash
of this concatenated value to obtain a 20-byte value, and of this concatenated value to obtain a 20-byte value, and
base64-encoding (see Section 4 of [RFC4648]) this 20-byte base64-encoding (see Section 4 of [RFC4648]) this 20-byte
hash. hash.
The ABNF of this header field is defined as follows: The ABNF [RFC2616] of this header field is defined as
follows:
Sec-WebSocket-Accept = base64-value-non-empty Sec-WebSocket-Accept = base64-value-non-empty
base64-value-non-empty = (1*base64-data [ base64-padding ]) | base64-value-non-empty = (1*base64-data [ base64-padding ]) |
base64-padding base64-padding
base64-value = *base64-data [ base64-padding ] base64-value = *base64-data [ base64-padding ]
base64-data = 4base64-character base64-data = 4base64-character
base64-padding = (2base64-character "==") | base64-padding = (2base64-character "==") |
(3base64-character "=") (3base64-character "=")
base64-character = ALPHA | DIGIT | "+" | "/" base64-character = ALPHA | DIGIT | "+" | "/"
skipping to change at page 27, line 31 skipping to change at page 27, line 32
WebSocket-Extensions header field. WebSocket-Extensions header field.
This completes the server's handshake. If the server finishes these This completes the server's handshake. If the server finishes these
steps without aborting the WebSocket handshake, the server considers steps without aborting the WebSocket handshake, the server considers
the WebSocket connection to be established and that the WebSocket the WebSocket connection to be established and that the WebSocket
connection is in the OPEN state. At this point, the server may begin connection is in the OPEN state. At this point, the server may begin
sending (and receiving) data. sending (and receiving) data.
4.3. Collected ABNF for new header fields used in handshake 4.3. Collected ABNF for new header fields used in handshake
Unlike other sections of the document this section is using ABNF This section is using ABNF syntax/rules from Section 2.1 of
syntax/rules from Section 2.1 of [RFC2616], including "implied *LWS [RFC2616], including "implied *LWS rule".
rule".
Note that the following ABNF conventions are used in this section: Note that the following ABNF conventions are used in this section:
Some names of the rules correspond to names of the corresponding Some names of the rules correspond to names of the corresponding
header fields. Such rules express values of the corresponding header header fields. Such rules express values of the corresponding header
fields, for example the Sec-WebSocket-Key ABNF rule describes syntax fields, for example the Sec-WebSocket-Key ABNF rule describes syntax
of the Sec-WebSocket-Key header field value. ABNF rules with the of the Sec-WebSocket-Key header field value. ABNF rules with the
"-Client" suffix in the name are only used in requests sent by the "-Client" suffix in the name are only used in requests sent by the
client to the server; ABNF rules with the "-Server" suffix in the client to the server; ABNF rules with the "-Server" suffix in the
name are only used in responses sent by the server to the client. name are only used in responses sent by the server to the client.
For example, the ABNF rule Sec-WebSocket-Protocol-Client describes For example, the ABNF rule Sec-WebSocket-Protocol-Client describes
skipping to change at page 28, line 48 skipping to change at page 28, line 48
This section provides some guidance on supporting multiple versions This section provides some guidance on supporting multiple versions
of the WebSocket protocol in clients and servers. of the WebSocket protocol in clients and servers.
Using the WebSocket version advertisement capability (the "Sec- Using the WebSocket version advertisement capability (the "Sec-
WebSocket-Version" header field) client can initially request the WebSocket-Version" header field) client can initially request the
version of the WebSocket protocol that it prefers (which doesn't version of the WebSocket protocol that it prefers (which doesn't
necessarily have to be the latest supported by the client). If the necessarily have to be the latest supported by the client). If the
server supports the requested version and the handshake message is server supports the requested version and the handshake message is
otherwise valid, the server will accept that version. If the server otherwise valid, the server will accept that version. If the server
doesn't support the requested version, it will respond with a Sec- doesn't support the requested version, it MUST respond with a Sec-
WebSocket-Version header field (or multiple Sec-WebSocket-Version WebSocket-Version header field (or multiple Sec-WebSocket-Version
header fields) containing all versions it is willing to use. At this header fields) containing all versions it is willing to use. At this
point, if the client supports one of the advertised versions, it can point, if the client supports one of the advertised versions, it can
repeat the WebSocket handshake using a new version value. repeat the WebSocket handshake using a new version value.
The following example demonstrates version negotiation described The following example demonstrates version negotiation described
above: above:
GET /chat HTTP/1.1 GET /chat HTTP/1.1
Host: server.example.com Host: server.example.com
skipping to change at page 30, line 10 skipping to change at page 30, line 10
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
... ...
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
5. Data Framing 5. Data Framing
5.1. Overview 5.1. Overview
In the WebSocket protocol, data is transmitted using a sequence of In the WebSocket protocol, data is transmitted using a sequence of
frames. All frames sent from the client to the server are masked to frames. To avoid confusing network intermediaries (such as
avoid confusing network intermediaries, such as intercepting proxies. intercepting proxies) and for security reasons that are further
All frames sent from the server to the client are not masked. discussed in Section 10.3, a client MUST mask all frames that it
sends to the server (see Section 5.3 for further details). The
server MUST close the connection upon receiving a frame that is not
masked. In this case, a server MAY send a close frame with a status
code of 1002 (protocol error) as defined in Section 7.4.1. A server
MUST NOT mask any frames that it sends to the client. A client MUST
close a connection if it detects a masked frame. In this case, it
MAY use the status code 1002 (protocol error) as defined in
Section 7.4.1. (These rules might be relaxed in a future
specification.)
The base framing protocol defines a frame type with an opcode, a The base framing protocol defines a frame type with an opcode, a
payload length, and designated locations for extension and payload length, and designated locations for extension and
application data, which together define the _payload_ data. Certain application data, which together define the _payload_ data. Certain
bits and opcodes are reserved for future expansion of the protocol. bits and opcodes are reserved for future expansion of the protocol.
A data frame MAY be transmitted by either the client or the server at A data frame MAY be transmitted by either the client or the server at
any time after opening handshake completion and before that endpoint any time after opening handshake completion and before that endpoint
has sent a close frame (Section 5.5.1). has sent a close frame (Section 5.5.1).
5.2. Base Framing Protocol 5.2. Base Framing Protocol
This wire format for the data transfer part is described by the ABNF This wire format for the data transfer part is described by the ABNF
[RFC5234] given in detail in this section. A high level overview of [RFC5234] given in detail in this section. A high level overview of
the framing is given in the following figure. the framing is given in the following figure. In a case of conflict
between the figure below and the ABNF specified later in this
section, the ABNF version should be considered to be more
authoritative.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+ +-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length | |F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/63) | |I|S|S|S| (4) |A| (7) | (16/63) |
|N|V|V|V| |S| | (if payload len==126/127) | |N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | | | |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 | | Extended payload length continued, if payload len == 127 |
skipping to change at page 33, line 30 skipping to change at page 33, line 41
; otherwise ; otherwise
frame-rsv2 = %x0 / %x1 frame-rsv2 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-rsv3 = %x0 / %x1 frame-rsv3 = %x0 / %x1
; 1 bit, MUST be 0 unless negotiated ; 1 bit, MUST be 0 unless negotiated
; otherwise ; otherwise
frame-opcode = %x0 ; continuation frame frame-opcode = frame-opcode-non-control /
/ %x1 ; text frame frame-opcode-control
frame-opcode-non-control= %x1 ; text frame
/ %x2 ; binary frame / %x2 ; binary frame
/ %x3-7 / %x3-7
; reserved for further non-control frames ; reserved for further non-control frames
/ %x8 ; connection close
frame-opcode-control = %x8 ; connection close
/ %x9 ; ping / %x9 ; ping
/ %xA ; pong / %xA ; pong
/ %xB-F ; reserved for further control frames / %xB-F ; reserved for further control frames
frame-masked = %x0 frame-masked = %x0
; frame is not masked, no frame-masking-key ; frame is not masked, no frame-masking-key
/ %x1 / %x1
; frame is masked, frame-masking-key present ; frame is masked, frame-masking-key present
frame-payload-length = %x00-7D frame-payload-length = %x00-7D
skipping to change at page 34, line 14 skipping to change at page 34, line 33
frame-masking-key = 4( %0x00-FF ) frame-masking-key = 4( %0x00-FF )
; present only if frame-masked is 1 ; present only if frame-masked is 1
frame-payload-data = (frame-masked-extension-data frame-payload-data = (frame-masked-extension-data
frame-masked-application-data) frame-masked-application-data)
; frame-masked 1 ; frame-masked 1
/ (frame-unmasked-extension-data / (frame-unmasked-extension-data
frame-unmasked-application-data) frame-unmasked-application-data)
; frame-masked 0 ; frame-masked 0
frame-masked-extension-data = *( %x00-FF ) ; to be defined later frame-masked-extension-data = *( %x00-FF )
; reserved for future extensibility
frame-masked-application-data = *( %x00-FF ) frame-masked-application-data = *( %x00-FF )
frame-unmasked-extension-data = *( %x00-FF ) ; to be defined later frame-unmasked-extension-data = *( %x00-FF )
; reserved for future extensibility
frame-unmasked-application-data = *( %x00-FF ) frame-unmasked-application-data = *( %x00-FF )
5.3. Client-to-Server Masking 5.3. Client-to-Server Masking
The client MUST mask all frames sent to the server. This is required
for security reasons which are further discussed in Section 10.3. A
server MUST close the connection upon receiving a frame with the MASK
bit set to 0. In this case, a server MAY send a close frame with a
status code of 1002 (protocol error) as defined in Section 7.4.1.
A masked frame MUST have the field frame-masked set to 1, as defined A masked frame MUST have the field frame-masked set to 1, as defined
in Section 5.2. in Section 5.2.
The masking key is contained completely within the frame, as defined The masking key is contained completely within the frame, as defined
in Section 5.2 as frame-masking-key. It is used to mask the payload in Section 5.2 as frame-masking-key. It is used to mask the payload
data defined in the same section as frame-payload-data, which data defined in the same section as frame-payload-data, which
includes extension and application data. includes extension and application data.
The masking key is a 32-bit value chosen at random by the client. The masking key is a 32-bit value chosen at random by the client.
The masking key MUST be derived from a strong source of entropy, and The masking key MUST be derived from a strong source of entropy, and
skipping to change at page 35, line 49 skipping to change at page 36, line 16
extensions were negotiated by the client and the server, or if some extensions were negotiated by the client and the server, or if some
extensions were negotiated, but the intermediary understood all the extensions were negotiated, but the intermediary understood all the
extensions negotiated and knows how to coalesce and/or split frames extensions negotiated and knows how to coalesce and/or split frames
in presence of these extensions. One implication of this is that in in presence of these extensions. One implication of this is that in
absence of extensions senders and receivers must not depend on absence of extensions senders and receivers must not depend on
presence of specific frame boundaries. presence of specific frame boundaries.
The following rules apply to fragmentation: The following rules apply to fragmentation:
o An unfragmented message consists of a single frame with the FIN o An unfragmented message consists of a single frame with the FIN
bit set and an opcode other than 0. bit set (Section 5.2) and an opcode other than 0.
o A fragmented message consists of a single frame with the FIN bit o A fragmented message consists of a single frame with the FIN bit
clear and an opcode other than 0, followed by zero or more frames clear and an opcode other than 0, followed by zero or more frames
with the FIN bit clear and the opcode set to 0, and terminated by with the FIN bit clear and the opcode set to 0, and terminated by
a single frame with the FIN bit set and an opcode of 0. A a single frame with the FIN bit set and an opcode of 0. A
fragmented message is conceptually equivalent to a single larger fragmented message is conceptually equivalent to a single larger
message whose payload is equal to the concatenation of the message whose payload is equal to the concatenation of the
payloads of the fragments in order, however in the presence of payloads of the fragments in order, however in the presence of
extensions this may not hold true as the extension defines the extensions this may not hold true as the extension defines the
interpretation of the extension data present. For instance, interpretation of the extension data present. For instance,
skipping to change at page 36, line 26 skipping to change at page 36, line 39
extension data present in each of the fragments that applies only extension data present in each of the fragments that applies only
to that particular fragment. In absence of extension data, the to that particular fragment. In absence of extension data, the
following example demonstrates how fragmentation works. following example demonstrates how fragmentation works.
EXAMPLE: For a text message sent as three fragments, the first EXAMPLE: For a text message sent as three fragments, the first
fragment would have an opcode of 0x1 and a FIN bit clear, the fragment would have an opcode of 0x1 and a FIN bit clear, the
second fragment would have an opcode of 0x0 and a FIN bit clear, second fragment would have an opcode of 0x0 and a FIN bit clear,
and the third fragment would have an opcode of 0x0 and a FIN bit and the third fragment would have an opcode of 0x0 and a FIN bit
that is set. that is set.
o Control frames MAY be injected in the middle of a fragmented o Control frames (see Section 5.5) MAY be injected in the middle of
message. Control frames themselves MUST NOT be fragmented. a fragmented message. Control frames themselves MUST NOT be
fragmented.
o Message fragments MUST be delivered to the recipient in the order o Message fragments MUST be delivered to the recipient in the order
sent by the sender. sent by the sender.
o The fragments of one message MUST NOT be interleaved between the o The fragments of one message MUST NOT be interleaved between the
fragments of another message unless an extension has been fragments of another message unless an extension has been
negotiated that can interpret the interleaving. negotiated that can interpret the interleaving.
o An endpoint MUST be capable of handling control frames in the o An endpoint MUST be capable of handling control frames in the
middle of a fragmented message. middle of a fragmented message.
skipping to change at page 52, line 20 skipping to change at page 52, line 20
by the client. If extension parameters are included in negotiations by the client. If extension parameters are included in negotiations
between the client and the server, those parameters MUST be chosen in between the client and the server, those parameters MUST be chosen in
accordance with the specification of the extension to which the accordance with the specification of the extension to which the
parameters apply. parameters apply.
9.1. Negotiating Extensions 9.1. Negotiating Extensions
A client requests extensions by including a "Sec-WebSocket- A client requests extensions by including a "Sec-WebSocket-
Extensions" header field, which follows the normal rules for HTTP Extensions" header field, which follows the normal rules for HTTP
header fields (see [RFC2616] section 4.2) and the value of the header header fields (see [RFC2616] section 4.2) and the value of the header
field is defined by the following ABNF. Note that unlike other field is defined by the following ABNF [RFC2616]. Note that this
sections of the document this section is using ABNF syntax/rules from section is using ABNF syntax/rules from [RFC2616], including "implied
[RFC2616], including "implied *LWS rule". If a value is received by *LWS rule". If a value is received by either the client or the
either the client or the server during negotiation that does not server during negotiation that does not conform to the ABNF below,
conform to the ABNF below, the recipient of such malformed data MUST the recipient of such malformed data MUST immediately _Fail the
immediately _Fail the WebSocket Connection_. WebSocket Connection_.
Sec-WebSocket-Extensions = extension-list Sec-WebSocket-Extensions = extension-list
extension-list = 1#extension extension-list = 1#extension
extension = extension-token *( ";" extension-param ) extension = extension-token *( ";" extension-param )
extension-token = registered-token extension-token = registered-token
registered-token = token registered-token = token
extension-param = token [ "=" (token | quoted-string) ] extension-param = token [ "=" (token | quoted-string) ]
;When using the quoted-string syntax variant, the value ;When using the quoted-string syntax variant, the value
;after quoted-string unescaping MUST conform to the 'token' ABNF. ;after quoted-string unescaping MUST conform to the 'token' ABNF.
skipping to change at page 56, line 37 skipping to change at page 56, line 37
Despite the protection provided by masking, non-compliant HTTP Despite the protection provided by masking, non-compliant HTTP
proxies will still be vulnerable to poisoning attacks of this type by proxies will still be vulnerable to poisoning attacks of this type by
clients and servers that do not apply masking. clients and servers that do not apply masking.
10.4. Implementation-Specific Limits 10.4. Implementation-Specific Limits
Implementations MUST impose implementation-specific limits on Implementations MUST impose implementation-specific limits on
otherwise unconstrained inputs, e.g. to prevent denial of service otherwise unconstrained inputs, e.g. to prevent denial of service
attacks, to guard against running out of memory, or to work around attacks, to guard against running out of memory, or to work around
platform-specific limitations. In particular, a malicious endpoint platform-specific limitations. In particular, a malicious endpoint
can try to exhaust its peer memory by sending either a single big can try to exhaust its peer's memory by sending either a single big
frame (e.g. of size 2**60), or by sending a long stream of small frame (e.g. of size 2**60), or by sending a long stream of small
frames which are a part of a fragmented message. In order to protect frames which are a part of a fragmented message. In order to protect
from this implementations SHOULD impose limit on frame sizes and the from this implementations SHOULD impose limit on frame sizes and the
total message size after reassembly from multiple frames. total message size after reassembly from multiple frames.
10.5. WebSocket client authentication 10.5. WebSocket client authentication
This protocol doesn't prescribe any particular way that servers can This protocol doesn't prescribe any particular way that servers can
authenticate clients during the WebSocket handshake. The WebSocket authenticate clients during the WebSocket handshake. The WebSocket
server can use any client authentication mechanism available to a server can use any client authentication mechanism available to a
skipping to change at page 57, line 48 skipping to change at page 57, line 48
A common class of security problems arise when sending text data A common class of security problems arise when sending text data
using using the wrong encoding. This protocol specifies that using using the wrong encoding. This protocol specifies that
messages with a Text data type (as opposed to Binary or other types) messages with a Text data type (as opposed to Binary or other types)
contain UTF-8 encoded data. Although the length is still indicated contain UTF-8 encoded data. Although the length is still indicated
and applications implementing this protocol should use the length to and applications implementing this protocol should use the length to
determine where the frame actually ends, sending data in an improper determine where the frame actually ends, sending data in an improper
encoding may still break assumptions applications built on top of encoding may still break assumptions applications built on top of
this protocol may make, leading from anything to misinterpretation of this protocol may make, leading from anything to misinterpretation of
data to loss of data to potential security bugs. data to loss of data to potential security bugs.
10.8. Use of SHA-1 by the WebSocket protocol 10.8. Use of SHA-1 by the WebSocket handshake
The protocol described in this document doesn't depend on any The WebSocket handshake described in this document doesn't depend on
security properties of SHA-1, such as collision resistence or any security properties of SHA-1, such as collision resistance or
resistence to the second pre-image attack (as described in resistance to the second pre-image attack (as described in
[RFC4270]). [RFC4270]).
11. IANA Considerations 11. IANA Considerations
11.1. Registration of new URI Schemes 11.1. Registration of new URI Schemes
11.1.1. Registration of "ws" Scheme 11.1.1. Registration of "ws" Scheme
A |ws| URI identifies a WebSocket server and resource name. A |ws| URI identifies a WebSocket server and resource name.
URI scheme name. URI scheme name.
ws ws
Status. Status.
Permanent. Permanent.
URI scheme syntax. URI scheme syntax.
In ABNF terms using the terminals from the URI specifications: In ABNF [RFC5234] terms using the terminals from the URI
[RFC5234] [RFC3986] specifications: [RFC5234] [RFC3986]
"ws:" "//" authority path-abempty [ "?" query ] "ws:" "//" authority path-abempty [ "?" query ]
The <path-abempty> and <query> [RFC3986] components form the The <path-abempty> and <query> [RFC3986] components form the
resource name sent to the server to identify the kind of service resource name sent to the server to identify the kind of service
desired. Other components have the meanings described in RFC3986. desired. Other components have the meanings described in RFC3986.
URI scheme semantics. URI scheme semantics.
The only operation for this scheme is to open a connection using The only operation for this scheme is to open a connection using
the WebSocket protocol. the WebSocket protocol.
Encoding considerations. Encoding considerations.
Characters in the host component that are excluded by the syntax Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by applying defined above MUST be converted from Unicode to ASCII as specified
the IDNA ToASCII algorithm to the Unicode host name, with both the in [RFC3987] or its replacement. For the purposes of scheme-based
AllowUnassigned and UseSTD3ASCIIRules flags set, and using the normalization IDN forms of the host component and their
result of this algorithm as the host in the URI. [RFC3490] conversions to punycode are considered equivalent (see Section
5.3.3 of [RFC3987]).
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.
skipping to change at page 60, line 31 skipping to change at page 60, line 34
TLS (including standard benefits of TLS such as data confidentiality TLS (including standard benefits of TLS such as data confidentiality
and integrity, and endpoint authentication). and integrity, and endpoint authentication).
URI scheme name. URI scheme name.
wss wss
Status. Status.
Permanent. Permanent.
URI scheme syntax. URI scheme syntax.
In ABNF terms using the terminals from the URI specifications: In ABNF [RFC5234] terms using the terminals from the URI
[RFC5234] [RFC3986] specifications: [RFC5234] [RFC3986]
"wss:" "//" authority path-abempty [ "?" query ] "wss:" "//" authority path-abempty [ "?" query ]
The <path-abempty> and <query> components form the resource name The <path-abempty> and <query> components form the resource name
sent to the server to identify the kind of service desired. Other sent to the server to identify the kind of service desired. Other
components have the meanings described in RFC3986. components have the meanings described in RFC3986.
URI scheme semantics. URI scheme semantics.
The only operation for this scheme is to open a connection using The only operation for this scheme is to open a connection using
the WebSocket protocol, encrypted using TLS. the WebSocket protocol, encrypted using TLS.
Encoding considerations. Encoding considerations.
Characters in the host component that are excluded by the syntax Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by applying defined above MUST be converted from Unicode to ASCII as specified
the IDNA ToASCII algorithm to the Unicode host name, with both the in [RFC3987] or its replacement. For the purposes of scheme-based
AllowUnassigned and UseSTD3ASCIIRules flags set, and using the normalization IDN forms of the host component and their
result of this algorithm as the host in the URI. [RFC3490] conversions to punycode are considered equivalent (see Section
5.3.3 of [RFC3987]).
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.
skipping to change at page 65, line 34 skipping to change at page 65, line 40
WebSocket handshake error, when the version received from the client WebSocket handshake error, when the version received from the client
does not match a version understood by the server. In such a case does not match a version understood by the server. In such a case
the header field includes the protocol version(s) supported by the the header field includes the protocol version(s) supported by the
server. server.
Note that there is no expectation that higher version numbers are Note that there is no expectation that higher version numbers are
necessarily backward compatible with lower version numbers. necessarily backward compatible with lower version numbers.
The |Sec-WebSocket-Version| header field MAY appear multiple times in The |Sec-WebSocket-Version| header field MAY appear multiple times in
an HTTP response (which is logically the same as a single |Sec- an HTTP response (which is logically the same as a single |Sec-
WebSocket-Protocol| header field that contains all values. However WebSocket-Version| header field that contains all values. However
the |Sec-WebSocket-Protocol| header field MUST NOT appear more than the |Sec-WebSocket-Version| header field MUST NOT appear more than
once in an HTTP request. once in an HTTP request.
11.4. WebSocket Extension Name Registry 11.4. WebSocket Extension Name Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Extension names to be used with the WebSocket protocol in WebSocket Extension names to be used with the WebSocket protocol in
accordance with the principles set out in RFC 5226 [RFC5226]. accordance with the principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
skipping to change at page 73, line 40 skipping to change at page 73, line 40
Thank you to the following people who participated in discussions on Thank you to the following people who participated in discussions on
the HYBI WG mailing list and contributed ideas and/or provided the HYBI WG mailing list and contributed ideas and/or provided
detailed reviews (the list is likely to be incomplete): Greg Wilkins, detailed reviews (the list is likely to be incomplete): Greg Wilkins,
John Tamplin, Willy Tarreau, Maciej Stachowiak, Jamie Lokier, Scott John Tamplin, Willy Tarreau, Maciej Stachowiak, Jamie Lokier, Scott
Ferguson, Bjoern Hoehrmann, Julian Reschke, Dave Cridland, Andy Ferguson, Bjoern Hoehrmann, Julian Reschke, Dave Cridland, Andy
Green, Eric Rescorla, Inaki Baz Castillo, Martin Thomson, Roberto Green, Eric Rescorla, Inaki Baz Castillo, Martin Thomson, Roberto
Peon, Patrick McManus, Zhong Yu, Bruce Atherton, Takeshi Yoshino, Peon, Patrick McManus, Zhong Yu, Bruce Atherton, Takeshi Yoshino,
Martin J. Duerst, James Graham, Simon Pieters, Roy T. Fielding, Martin J. Duerst, James Graham, Simon Pieters, Roy T. Fielding,
Mykyta Yevstifeyev, Len Holgate, Paul Colomiets, Piotr Kulaga, Brian Mykyta Yevstifeyev, Len Holgate, Paul Colomiets, Piotr Kulaga, Brian
Raymor, Jan Koehler, Joonas Lehtolahti, Sylvain Hellegouarch, Stephen Raymor, Jan Koehler, Joonas Lehtolahti, Sylvain Hellegouarch, Stephen
Farrell, Pete Resnick. Note that people listed above didn't Farrell, Sean Turner, Pete Resnick, Peter Thorson, Joe Mason. Note
necessarily endorse the end result of this work. that people listed above didn't necessarily endorse the end result of
this work.
14. References 14. References
14.1. Normative References 14.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
skipping to change at page 74, line 35 skipping to change at page 74, line 35
[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,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 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 77, line 5 skipping to change at page 76, line 10
Saldhana, A. and T. Roessler, "Web Security Context: User Saldhana, A. and T. Roessler, "Web Security Context: User
Interface Guidelines", World Wide Web Consortium Interface Guidelines", World Wide Web Consortium
Recommendation REC-wsc-ui-20100812, August 2010, Recommendation REC-wsc-ui-20100812, August 2010,
<http://www.w3.org/TR/2010/REC-wsc-ui-20100812>. <http://www.w3.org/TR/2010/REC-wsc-ui-20100812>.
[TALKING] Huang, L-S., Chen, E., Barth, A., and E. Rescorla, [TALKING] Huang, L-S., Chen, E., Barth, A., and E. Rescorla,
"Talking to Yourself for Fun and Profit", 2010, <http:// "Talking to Yourself for Fun and Profit", 2010, <http://
www.adambarth.com/papers/2011/ www.adambarth.com/papers/2011/
huang-chen-barth-rescorla-jackson.pdf>. huang-chen-barth-rescorla-jackson.pdf>.
[XMLHttpRequest]
van Kesteren, A., Ed., "XMLHttpRequest", August 2010,
<http://www.w3.org/TR/XMLHttpRequest/>.
Authors' Addresses Authors' Addresses
Ian Fette Ian Fette
Google, Inc. Google, Inc.
Email: ifette+ietf@google.com Email: ifette+ietf@google.com
URI: http://www.ianfette.com/ URI: http://www.ianfette.com/
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
 End of changes. 38 change blocks. 
69 lines changed or deleted 88 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/