idnits 2.17.1 draft-hixie-thewebsocketprotocol-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([HTML5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 8, 2009) is 5407 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML5' ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Hickson 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track July 8, 2009 5 Expires: January 9, 2010 7 The Web Socket protocol 8 draft-hixie-thewebsocketprotocol-20 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 9, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This protocol enables two-way communication between a user agent 47 running untrusted code running in a controlled environment to a 48 remote host that understands the protocol. It is intended to fail to 49 communicate with servers of pre-existing protocols like SMTP or HTTP, 50 while allowing HTTP servers to opt-in to supporting this protocol if 51 desired. It is designed to be easy to implement on the server side. 53 Author's note 55 This document is automatically generated from the same source 56 document as the HTML5 specification. [HTML5] 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Security model . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conformance requirements . . . . . . . . . . . . . . . . . . . 5 63 3. Client-side requirements . . . . . . . . . . . . . . . . . . . 6 64 3.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Data framing . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.3. Handling errors in UTF-8 . . . . . . . . . . . . . . . . . 14 67 4. Server-side requirements . . . . . . . . . . . . . . . . . . . 15 68 4.1. Minimal handshake . . . . . . . . . . . . . . . . . . . . 15 69 4.2. Handshake details . . . . . . . . . . . . . . . . . . . . 16 70 4.3. Data framing . . . . . . . . . . . . . . . . . . . . . . . 17 71 5. Closing the connection . . . . . . . . . . . . . . . . . . . . 18 72 6. Security considerations . . . . . . . . . . . . . . . . . . . 19 73 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 21 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 1. Introduction 79 The Web Socket protocol is designed on the principle that there 80 should be minimal framing (the only framing that exists is to make 81 the protocol frame-based instead of stream-based, and to support a 82 distinction between Unicode text and binary frames). It is expected 83 that metadata would be layered on top of Web Socket by the 84 application layer, in the same way that metadata is layered on top of 85 TCP/IP by the application layer (HTTP). 87 Conceptually, Web Socket is really just a layer on top of TCP/IP that 88 adds a Web "origin"-based security model for browsers; adds an 89 addressing and protocol naming mechanism to support multiple services 90 on one port and multiple host names on one IP address; and layers a 91 framing mechanism on top of TCP to get back to the IP packet 92 mechanism that TCP is built on, but without length limits. Other 93 than that, it adds nothing. Basically it is intended to be as close 94 as possible to just exposing raw TCP/IP to script as possible given 95 the constraints of the Web. It's also designed in such a way that its 96 servers can share a port with HTTP servers, by having its handshake 97 be a valid HTTP Upgrade handshake also. 99 1.1. Security model 101 The Web Socket protocol uses the origin model used by Web browsers to 102 restrict which Web pages can contact a Web Socket server when the Web 103 Socket protocol is used from a Web page. Naturally, when the Web 104 Socket protocol is used directly (not from a Web page), the origin 105 model is not useful, as the client can provide any arbitrary origin 106 string. 108 2. Conformance requirements 110 All diagrams, examples, and notes in this specification are non- 111 normative, as are all sections explicitly marked non-normative. 112 Everything else in this specification is normative. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 115 "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this 116 document are to be interpreted as described in RFC2119. For 117 readability, these words do not appear in all uppercase letters in 118 this specification. [RFC2119] 120 Requirements phrased in the imperative as part of algorithms (such as 121 "strip any leading space characters" or "return false and abort these 122 steps") are to be interpreted with the meaning of the key word 123 ("must", "should", "may", etc) used in introducing the algorithm. 125 Conformance requirements phrased as algorithms or specific steps may 126 be implemented in any manner, so long as the end result is 127 equivalent. (In particular, the algorithms defined in this 128 specification are intended to be easy to follow, and not intended to 129 be performant.) 131 Implementations may impose implementation-specific limits on 132 otherwise unconstrained inputs, e.g. to prevent denial of service 133 attacks, to guard against running out of memory, or to work around 134 platform-specific limitations. 136 The conformance classes defined by this specification are user agents 137 and servers. 139 3. Client-side requirements 141 _This section only applies to user agents, not to servers._ 143 NOTE: This specification doesn't currently define a limit to the 144 number of simultaneous connections that a client can establish to a 145 server. 147 3.1. Handshake 149 When the user agent is to *establish a Web Socket connection* to a 150 host /host/, optionally on port /port/, from an origin /origin/, with 151 a flag /secure/, with a particular /resource name/, and optionally 152 with a particular /protocol/, it must run the following steps. 154 NOTE: The /host/ and /origin/ strings will be all-lowercase when this 155 algorithm is invoked. 157 1. If there is no explicit /port/, then: if /secure/ is false, let 158 /port/ be 81, otherwise let /port/ be 815. 160 2. If the user agent already has a Web Socket connection to the 161 remote host identified by /host/ (even if known by another 162 name), wait until that connection has been established or for 163 that connection to have failed. 165 NOTE: This makes it harder for a script to perform a denial of 166 service attack by just opening a large number of Web Socket 167 connections to a remote host. 169 NOTE: There is no limit to the number of established Web Socket 170 connections a user agent can have with a single remote host. 171 Servers can refuse to connect users with an excessive number of 172 connections, or disconnect resource-hogging users when suffering 173 high load. 175 3. If the user agent is configured to use a proxy when using the 176 WebSocket protocol to connect to host /host/ and/or port /port/, 177 then connect to that proxy and ask it to open a TCP/IP 178 connection to the host given by /host/ and the port given by 179 /port/. 181 EXAMPLE: For example, if the user agent uses an HTTP proxy 182 for all traffic, then if it was to try to connect to port 80 183 on server example.com, it might send the following lines to 184 the proxy server: 186 CONNECT example.com:80 HTTP/1.1 187 Host: example.com 189 If there was a password, the connection might look like: 191 CONNECT example.com:80 HTTP/1.1 192 Host: example.com 193 Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE= 195 Otherwise, if the user agent is not configured to use a proxy, 196 then open a TCP/IP connection to the host given by /host/ and 197 the port given by /port/. 199 NOTE: Implementations that do not expose explicit UI for 200 selecting a proxy for WebSocket connections separate from other 201 proxies are encouraged to use a SOCKS proxy for WebSocket 202 connections, if available, or failing that, to prefer an HTTPS 203 proxy over an HTTP proxy. 205 4. If the connection could not be opened, then fail the Web Socket 206 connection and abort these steps. 208 5. If /secure/ is true, perform a TLS handshake over the 209 connection. If this fails (e.g. the server's certificate could 210 not be verified), then fail the Web Socket connection and abort 211 these steps. Otherwise, all further communication on this 212 channel must run through the encrypted tunnel. [RFC2246] 214 6. Send the following bytes to the remote side (the server): 216 47 45 54 20 218 Send the /resource name/ value, encoded as US-ASCII. 220 Send the following bytes: 222 20 48 54 54 50 2f 31 2e 31 0d 0a 55 70 67 72 61 223 64 65 3a 20 57 65 62 53 6f 63 6b 65 74 0d 0a 43 224 6f 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 67 72 61 225 64 65 0d 0a 227 NOTE: The string "GET ", the path, " HTTP/1.1", CRLF, the string 228 "Upgrade: WebSocket", CRLF, and the string "Connection: 229 Upgrade", CRLF. 231 7. Send the following bytes: 233 48 6f 73 74 3a 20 235 Send the /host/ value, encoded as US-ASCII. 237 Send the following bytes: 239 0d 0a 241 NOTE: The string "Host: ", the host, and CRLF. 243 8. Send the following bytes: 245 4f 72 69 67 69 6e 3a 20 247 Send the /origin/ value, encoded as US-ASCII. 249 NOTE: The /origin/ value is a string that was passed to this 250 algorithm. 252 Send the following bytes: 254 0d 0a 256 NOTE: The string "Origin: ", the origin, and CRLF. 258 9. If there is no /protocol/, then skip this step. 260 Otherwise, send the following bytes: 262 57 65 62 53 6f 63 6b 65 74 2d 50 72 6f 74 6f 63 263 6f 6c 3a 20 265 Send the /protocol/ value, encoded as US-ASCII. 267 Send the following bytes: 269 0d 0a 271 NOTE: The string "WebSocket-Protocol: ", the protocol, and CRLF. 273 10. If the client has any authentication information or cookies that 274 would be relevant to a resource accessed over HTTP, if /secure/ 275 is false, or HTTPS, if it is true, on host /host/, port /port/, 276 with /resource name/ as the path (and possibly query 277 parameters), then HTTP headers that would be appropriate for 278 that information should be sent at this point. [RFC2616] 279 [RFC2109] [RFC2965] 281 Each header must be on a line of its own (each ending with a CR 282 LF sequence). For the purposes of this step, each header must 283 not be split into multiple lines (despite HTTP otherwise 284 allowing this with continuation lines). 286 EXAMPLE: For example, if the server had a username and 287 password that applied to |http://example.com/socket|, and the 288 Web Socket was being opened to |ws://example.com:80/socket|, 289 it could send them: 291 Authorization: Basic d2FsbGU6ZXZl 293 However, it would not send them if the Web Socket was being 294 opened to |ws://example.com/socket|, as that uses a different 295 port (81, not 80). 297 11. Send the following bytes: 299 0d 0a 301 NOTE: Just a CRLF (a blank line). 303 12. Read the first 85 bytes from the server. If the connection 304 closes before 85 bytes are received, or if the first 85 bytes 305 aren't exactly equal to the following bytes, then fail the Web 306 Socket connection and abort these steps. 308 48 54 54 50 2f 31 2e 31 20 31 30 31 20 57 65 62 309 20 53 6f 63 6b 65 74 20 50 72 6f 74 6f 63 6f 6c 310 20 48 61 6e 64 73 68 61 6b 65 0d 0a 55 70 67 72 311 61 64 65 3a 20 57 65 62 53 6f 63 6b 65 74 0d 0a 312 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 67 72 313 61 64 65 0d 0a 315 NOTE: The string "HTTP/1.1 101 Web Socket Protocol Handshake", 316 CRLF, the string "Upgrade: WebSocket", CRLF, the string 317 "Connection: Upgrade", CRLF. 319 User agents may apply a timeout to this step, failing the Web 320 Socket connection if the server does not respond with the above 321 bytes within a suitable time period. 323 13. Let /headers/ be a list of name-value pairs, initially empty. 325 14. _Header_: Let /name/ and /value/ be empty byte arrays. 327 15. Read a byte from the server. 329 If the connection closes before this byte is received, then fail 330 the Web Socket connection and abort these steps. 332 Otherwise, handle the byte as described in the appropriate entry 333 below: 335 -> If the byte is 0x0d (ASCII CR) 336 If the /name/ byte array is empty, then jump to the headers 337 processing step. Otherwise, fail the Web Socket connection 338 and abort these steps. 340 -> If the byte is 0x0a (ASCII LF) 341 Fail the Web Socket connection and abort these steps. 343 -> If the byte is 0x3a (ASCII ":") 344 Move on to the next step. 346 -> If the byte is in the range 0x41 .. 0x5a (ASCII "A" .. "Z") 347 Append a byte whose value is the byte's value plus 0x20 to 348 the /name/ byte array and redo this step for the next byte. 350 -> Otherwise 351 Append the byte to the /name/ byte array and redo this step 352 for the next byte. 354 NOTE: This reads a header name, terminated by a colon, 355 converting upper-case ASCII letters to lowercase, and aborting 356 if a stray CR or LF is found. 358 16. Read a byte from the server. 360 If the connection closes before this byte is received, then fail 361 the Web Socket connection and abort these steps. 363 Otherwise, handle the byte as described in the appropriate entry 364 below: 366 -> If the byte is 0x20 (ASCII space) 367 Ignore the byte and move on to the next step. 369 -> Otherwise 370 Treat the byte as described by the list in the next step, 371 then move on to that next step for real. 373 NOTE: This skips past a space character after the colon, if 374 necessary. 376 17. Read a byte from the server. 378 If the connection closes before this byte is received, then fail 379 the Web Socket connection and abort these steps. 381 Otherwise, handle the byte as described in the appropriate entry 382 below: 384 -> If the byte is 0x0d (ASCII CR) 385 Move on to the next step. 387 -> If the byte is 0x0a (ASCII LF) 388 Fail the Web Socket connection and abort these steps. 390 -> Otherwise 391 Append the byte to the /name/ byte array and redo this step 392 for the next byte. 394 NOTE: This reads a header value, terminated by a CRLF. 396 18. Read a byte from the server. 398 If the connection closes before this byte is received, or if the 399 byte is not a 0x0a byte (ASCII LF), then fail the Web Socket 400 connection and abort these steps. 402 NOTE: This skips past the LF byte of the CRLF after the header. 404 19. Append an entry to the /headers/ list that has the name given by 405 the string obtained by interpreting the /name/ byte array as a 406 UTF-8 byte stream and the value given by the string obtained by 407 interpreting the /value/ byte array as a UTF-8 byte stream. 409 20. Return to the "Header" step above. 411 21. _Headers processing_: If there is not exactly one entry in the 412 /headers/ list whose name is "websocket-origin", or if there is 413 not exactly one entry in the /headers/ list whose name is 414 "websocket-location", or if the /protocol/ was specified but 415 there is not exactly one entry in the /headers/ list whose name 416 is "websocket-protocol", or if there are any entries in the 417 /headers/ list whose names are the empty string, then fail the 418 Web Socket connection and abort these steps. 420 22. Read a byte from the server. 422 If the connection closes before this byte is received, or if the 423 byte is not a 0x0a byte (ASCII LF), then fail the Web Socket 424 connection and abort these steps. 426 NOTE: This skips past the LF byte of the CRLF after the blank 427 line after the headers. 429 23. Handle each entry in the /headers/ list as follows: 431 -> If the entry's name is "websocket-origin|" 432 If the value is not exactly equal to /origin/, converted to 433 ASCII lowercase, then fail the Web Socket connection and 434 abort these steps. 436 -> If the entry's name is "websocket-location|" 437 If the value is not exactly equal to a string consisting of 438 the following components in the same order, then fail the Web 439 Socket connection and abort these steps: 441 1. The string "ws" if /secure/ is false and "wss" if 442 /secure/ is true 444 2. The three characters "://". 446 3. The value of /host/. 448 4. If /secure/ is false and /port/ is not 81, or if /secure/ 449 is true and /port/ is not 815: a ":" character followed 450 by the value of /port/. 452 5. The value of /resource name/. 454 -> If the entry's name is "websocket-protocol|" 455 If there was a /protocol/ specified, and the value is not 456 exactly equal to /protocol/, then fail the Web Socket 457 connection and abort these steps. (If no /protocol/ was 458 specified, the header is ignored.) 460 -> If the entry's name is "set-cookie|" or "set-cookie2|" or 461 another cookie-related header name 462 Handle the cookie as defined by the appropriate spec, with 463 the resource being the one with the host /host/, the port 464 /port/, the path (and possibly query parameters) /resource 465 name/, and the scheme |http| if /secure/ is false and |https| 466 if /secure/ is true. [RFC2109] [RFC2965] 468 -> Any other name 469 Ignore it. 471 24. The *Web Socket connection is established*. Now the user agent 472 must send and receive to and from the connection as described in 473 the next section. 475 To *fail the Web Socket connection*, the user agent must close the 476 Web Socket connection, and may report the problem to the user (which 477 would be especially useful for developers). However, user agents 478 must not convey the failure information to the script that attempted 479 the connection in a way distinguishable from the Web Socket being 480 closed normally. 482 3.2. Data framing 484 Once a Web Socket connection is established, the user agent must run 485 through the following state machine for the bytes sent by the server. 487 1. Try to read a byte from the server. Let /frame type/ be that 488 byte. 490 If no byte could be read because the Web Socket connection is 491 closed, then abort. 493 2. Handle the /frame type/ byte as follows: 495 If the high-order bit of the /frame type/ byte is set (i.e. if 496 /frame type/ _and_ed with 0x80 returns 0x80) 497 Run these steps. If at any point during these steps a read is 498 attempted but fails because the Web Socket connection is 499 closed, then abort. 501 1. Let /length/ be zero. 503 2. _Length_: Read a byte, let /b/ be that byte. 505 3. Let /b_v/ be integer corresponding to the low 7 bits of 506 /b/ (the value you would get by _and_ing /b/ with 0x7f). 508 4. Multiply /length/ by 128, add /b_v/ to that result, and 509 store the final result in /length/. 511 5. If the high-order bit of /b/ is set (i.e. if /b/ _and_ed 512 with 0x80 returns 0x80), then return to the step above 513 labeled _length_. 515 6. Read /length/ bytes. 517 7. Discard the read bytes. 519 If the high-order bit of the /frame type/ byte is _not_ set (i.e. 520 if /frame type/ _and_ed with 0x80 returns 0x00) 521 Run these steps. If at any point during these steps a read is 522 attempted but fails because the Web Socket connection is 523 closed, then abort. 525 1. Let /raw data/ be an empty byte array. 527 2. _Data_: Read a byte, let /b/ be that byte. 529 3. If /b/ is not 0xff, then append /b/ to /raw data/ and 530 return to the previous step (labeled _data_). 532 4. Interpret /raw data/ as a UTF-8 string, and store that 533 string in /data/. 535 5. If /frame type/ is 0x00, then *a message has been 536 received* with text /data/. Otherwise, discard the data. 538 3. Return to the first step to read the next byte. 540 If the user agent is faced with content that is too large to be 541 handled appropriately, then it must fail the Web Socket connection. 543 Once a Web Socket connection is established, the user agent must use 544 the following steps to *send /data/ using the Web Socket*: 546 1. Send a 0x00 byte to the server. 548 2. Encode /data/ using UTF-8 and send the resulting byte stream to 549 the server. 551 3. Send a 0xff byte to the server. 553 3.3. Handling errors in UTF-8 555 When a client is to interpret a byte stream as UTF-8 but finds that 556 the byte stream is not in fact a valid UTF-8 stream, then any bytes 557 or sequences of bytes that are not valid UTF-8 sequences must be 558 interpreted as a U+FFFD REPLACEMENT CHARACTER. 560 4. Server-side requirements 562 _This section only applies to servers._ 564 4.1. Minimal handshake 566 NOTE: This section describes the minimal requirements for a server- 567 side implementation of Web Sockets. 569 Listen on a port for TCP/IP. Upon receiving a connection request, 570 open a connection and send the following bytes back to the client: 572 48 54 54 50 2f 31 2e 31 20 31 30 31 20 57 65 62 573 20 53 6f 63 6b 65 74 20 50 72 6f 74 6f 63 6f 6c 574 20 48 61 6e 64 73 68 61 6b 65 0d 0a 55 70 67 72 575 61 64 65 3a 20 57 65 62 53 6f 63 6b 65 74 0d 0a 576 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 67 72 577 61 64 65 0d 0a 579 Send the string "WebSocket-Origin" followed by a U+003A COLON (":") 580 followed by the ASCII serialization of the origin from which the 581 server is willing to accept connections, followed by a CRLF pair 582 (0x0d 0x0a). 584 For instance: 586 WebSocket-Origin: http://example.com 588 Send the string "WebSocket-Location" followed by a U+003A COLON (":") 589 followed by the URL of the Web Socket script, followed by a CRLF pair 590 (0x0d 0x0a). 592 For instance: 594 WebSocket-Location: ws://example.com:80/demo 596 Send another CRLF pair (0x0d 0x0a). 598 Read data from the client until four bytes 0x0d 0x0a 0x0d 0x0a are 599 read. This data must either be discarded or handled as described in 600 the following section describing the handshake details. 602 If the connection isn't dropped at this point, go to the data framing 603 section. 605 4.2. Handshake details 607 The previous section ignores the data that is transmitted by the 608 client during the handshake. 610 The data sent by the client consists of a number of fields separated 611 by CR LF pairs (bytes 0x0d 0x0a). 613 The first field consists of three tokens separated by space 614 characters (byte 0x20). The middle token is the path being opened. 615 If the server supports multiple paths, then the server should echo 616 the value of this field in the initial handshake, as part of the URL 617 given on the |WebSocket-Location| line (after the appropriate scheme 618 and host). 620 If the first field does not have three tokens, the server should 621 abort the connection as it probably represents an errorneous client. 623 The remaining fields consist of name-value pairs, with the name part 624 separated from the value part by a colon and a space (bytes 0x3a 625 0x20). Of these, several are interesting: 627 Host (bytes 48 6f 73 74) 628 The value gives the hostname that the client intended to use when 629 opening the Web Socket. It would be of interest in particular to 630 virtual hosting environments, where one server might serve 631 multiple hosts, and might therefore want to return different data. 633 The right host has to be output as part of the URL given on the 634 |WebSocket-Location| line of the handshake described above, to 635 verify that the server knows that it is really representing that 636 host. 638 Origin (bytes 4f 72 69 67 69 6e) 639 The value gives the scheme, hostname, and port (if it's not the 640 default port for the given scheme) of the page that asked the 641 client to open the Web Socket. It would be interesting if the 642 server's operator had deals with operators of other sites, since 643 the server could then decide how to respond (or indeed, _whether_ 644 to respond) based on which site was requesting a connection. 646 If the server supports connections from more than one origin, then 647 the server should echo the value of this field in the initial 648 handshake, on the |WebSocket-Origin| line. 650 Other fields 651 Other fields can be used, such as "Cookie" or "Authorization", for 652 authentication purposes. 654 Any fields that lack the colon-space separator should be discarded 655 and may cause the server to disconnect. 657 4.3. Data framing 659 NOTE: This section only describes how to handle content that this 660 specification allows user agents to send (text). It doesn't handle 661 any arbitrary content in the same way that the requirements on user 662 agents defined earlier handle any content including possible future 663 extensions to the protocols. 665 The server must run through the following steps to process the bytes 666 sent by the client: 668 1. Read a byte from the client. Assuming everything is going 669 according to plan, it will be a 0x00 byte. If the byte is not a 670 0x00 byte, then the server may disconnect. 672 2. Let /raw data/ be an empty byte array. 674 3. _Data_: Read a byte, let /b/ be that byte. 676 4. If /b/ is not 0xff, then append /b/ to /raw data/ and return to 677 the previous step (labeled _data_). 679 5. Interpret /raw data/ as a UTF-8 string, and apply whatever 680 server-specific processing is to occur for the resulting string. 682 6. Return to the first step to read the next byte. 684 The server must run through the following steps to send strings to 685 the client: 687 1. Send a 0x00 byte to the client to indicate the start of a string. 689 2. Encode /data/ using UTF-8 and send the resulting byte stream to 690 the client. 692 3. Send a 0xff byte to the client to indicate the end of the 693 message. 695 5. Closing the connection 697 To *close the Web Socket connection*, either the user agent or the 698 server closes the TCP/IP connection. There is no closing handshake. 699 Whether the user agent or the server closes the connection, it is 700 said that the *Web Socket connection is closed*. 702 Servers may close the Web Socket connection whenever desired. 704 User agents should not close the Web Socket connection arbitrarily. 706 6. Security considerations 708 ** ISSUE ** ... 710 7. IANA considerations 712 ** ISSUE ** ...(two URI schemes, two ports, HTTP Upgrade keyword) 714 8. Normative References 716 [HTML5] Hickson, I., "HTML5", July 2009. 718 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 719 Mechanism", RFC 2109, February 1997. 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, March 1997. 724 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 725 RFC 2246, January 1999. 727 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 728 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 729 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 731 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 732 Mechanism", RFC 2965, October 2000. 734 Author's Address 736 Ian Hickson 737 Google, Inc. 739 Email: ian@hixie.ch 740 URI: http://ln.hixie.ch/