a guest May 21st, 2012 231 Never
  1. Server condump
  3. Input:
  4. GET / HTTP/1.1
  5. Host:
  6. User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:12.0) Gecko/20100101 Firefox/
  7. 12.0
  8. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  9. Accept-Language: en-us,en;q=0.5
  10. Accept-Encoding: gzip, deflate
  11. Connection: keep-alive, Upgrade
  12. Sec-WebSocket-Version: 13
  13. Origin:
  14. Sec-WebSocket-Key: iTAsnxQZ045LBMzPRnlYGg==
  15. Pragma: no-cache
  16. Cache-Control: no-cache
  17. Upgrade: websocket
  20. Key: iTAsnxQZ045LBMzPRnlYGg==
  22. Sending Response:
  23. GET / HTTP/1.1 400 Bad request
  24. Upgrade: websocket
  25. Connection: Upgrade
  26. Sec-WebSocket-Accept: lDvWhu8hXx1WwZQ+pK0bQiugEBY=
  29. 4.2.2.  Sending the Server's Opening Handshake
  31.    When a client establishes a WebSocket connection to a server, the
  32.    server MUST complete the following steps to accept the connection and
  33.    send the server's opening handshake.
  35.    1.  If the connection is happening on an HTTPS (HTTP-over-TLS) port,
  36.        perform a TLS handshake over the connection.  If this fails
  37.        (e.g., the client indicated a host name in the extended client
  38.        hello "server_name" extension that the server does not host),
  39.        then close the connection; otherwise, all further communication
  40.        for the connection (including the server's handshake) MUST run
  41.        through the encrypted tunnel [RFC5246].
  43.    2.  The server can perform additional client authentication, for
  44.        example, by returning a 401 status code with the corresponding
  45.        |WWW-Authenticate| header field as described in [RFC2616].
  47.    3.  The server MAY redirect the client using a 3xx status code
  48.        [RFC2616].  Note that this step can happen together with, before,
  49.        or after the optional authentication step described above.
  51.    4.  Establish the following information:
  53.        /origin/
  54.           The |Origin| header field in the client's handshake indicates
  55.           the origin of the script establishing the connection.  The
  56.           origin is serialized to ASCII and converted to lowercase.  The
  57.           server MAY use this information as part of a determination of
  58.           whether to accept the incoming connection.  If the server does
  59.           not validate the origin, it will accept connections from
  60.           anywhere.  If the server does not wish to accept this
  61.           connection, it MUST return an appropriate HTTP error code
  62.           (e.g., 403 Forbidden) and abort the WebSocket handshake
  63.           described in this section.  For more detail, refer to
  64.           Section 10.
  66.        /key/
  67.           The |Sec-WebSocket-Key| header field in the client's handshake
  68.           includes a base64-encoded value that, if decoded, is 16 bytes
  69.           in length.  This (encoded) value is used in the creation of
  70.           the server's handshake to indicate an acceptance of the
  71.           connection.  It is not necessary for the server to base64-
  72.           decode the |Sec-WebSocket-Key| value.
  74. Fette & Melnikov             Standards Track                   [Page 22]
  75. RFC 6455                 The WebSocket Protocol            December 2011
  77.        /version/
  78.           The |Sec-WebSocket-Version| header field in the client's
  79.           handshake includes the version of the WebSocket Protocol with
  80.           which the client is attempting to communicate.  If this
  81.           version does not match a version understood by the server, the
  82.           server MUST abort the WebSocket handshake described in this
  83.           section and instead send an appropriate HTTP error code (such
  84.           as 426 Upgrade Required) and a |Sec-WebSocket-Version| header
  85.           field indicating the version(s) the server is capable of
  86.           understanding.
  88.        /resource name/
  89.           An identifier for the service provided by the server.  If the
  90.           server provides multiple services, then the value should be
  91.           derived from the resource name given in the client's handshake
  92.           in the "Request-URI" [RFC2616] of the GET method.  If the
  93.           requested service is not available, the server MUST send an
  94.           appropriate HTTP error code (such as 404 Not Found) and abort
  95.           the WebSocket handshake.
  97.        /subprotocol/
  98.           Either a single value representing the subprotocol the server
  99.           is ready to use or null.  The value chosen MUST be derived
  100.           from the client's handshake, specifically by selecting one of
  101.           the values from the |Sec-WebSocket-Protocol| field that the
  102.           server is willing to use for this connection (if any).  If the
  103.           client's handshake did not contain such a header field or if
  104.           the server does not agree to any of the client's requested
  105.           subprotocols, the only acceptable value is null.  The absence
  106.           of such a field is equivalent to the null value (meaning that
  107.           if the server does not wish to agree to one of the suggested
  108.           subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol|
  109.           header field in its response).  The empty string is not the
  110.           same as the null value for these purposes and is not a legal
  111.           value for this field.  The ABNF for the value of this header
  112.           field is (token), where the definitions of constructs and
  113.           rules are as given in [RFC2616].
  115.        /extensions/
  116.           A (possibly empty) list representing the protocol-level
  117.           extensions the server is ready to use.  If the server supports
  118.           multiple extensions, then the value MUST be derived from the
  119.           client's handshake, specifically by selecting one or more of
  120.           the values from the |Sec-WebSocket-Extensions| field.  The
  121.           absence of such a field is equivalent to the null value.  The
  122.           empty string is not the same as the null value for these
  124. Fette & Melnikov             Standards Track                   [Page 23]
  125. RFC 6455                 The WebSocket Protocol            December 2011
  127.           purposes.  Extensions not listed by the client MUST NOT be
  128.           listed.  The method by which these values should be selected
  129.           and interpreted is discussed in Section 9.1.
  131.    5.  If the server chooses to accept the incoming connection, it MUST
  132.        reply with a valid HTTP response indicating the following.
  134.        1.  A Status-Line with a 101 response code as per RFC 2616
  135.            [RFC2616].  Such a response could look like "HTTP/1.1 101
  136.            Switching Protocols".
  138.        2.  An |Upgrade| header field with value "websocket" as per RFC
  139.            2616 [RFC2616].
  141.        3.  A |Connection| header field with value "Upgrade".
  143.        4.  A |Sec-WebSocket-Accept| header field.  The value of this
  144.            header field is constructed by concatenating /key/, defined
  145.            above in step 4 in Section 4.2.2, with the string "258EAFA5-
  146.            E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this
  147.            concatenated value to obtain a 20-byte value and base64-
  148.            encoding (see Section 4 of [RFC4648]) this 20-byte hash.
  150.            The ABNF [RFC2616] of this header field is defined as
  151.            follows:
  153.            Sec-WebSocket-Accept     = base64-value-non-empty
  154.            base64-value-non-empty = (1*base64-data [ base64-padding ]) |
  155.                                     base64-padding
  156.            base64-data      = 4base64-character
  157.            base64-padding   = (2base64-character "==") |
  158.                               (3base64-character "=")
  159.            base64-character = ALPHA | DIGIT | "+" | "/"
  161.    NOTE: As an example, if the value of the |Sec-WebSocket-Key| header
  162.    field in the client's handshake were "dGhlIHNhbXBsZSBub25jZQ==", the
  163.    server would append the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
  164.    to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
  165.    C5AB0DC85B11".  The server would then take the SHA-1 hash of this
  166.    string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90
  167.    0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea.  This value
  168.    is then base64-encoded, to give the value
  169.    "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned in the
  170.    |Sec-WebSocket-Accept| header field.
  172.        5.  Optionally, a |Sec-WebSocket-Protocol| header field, with a
  173.            value /subprotocol/ as defined in step 4 in Section 4.2.2.
  175. Fette & Melnikov             Standards Track                   [Page 24]
  176. RFC 6455                 The WebSocket Protocol            December 2011
  178.        6.  Optionally, a |Sec-WebSocket-Extensions| header field, with a
  179.            value /extensions/ as defined in step 4 in Section 4.2.2.  If
  180.            multiple extensions are to be used, they can all be listed in
  181.            a single |Sec-WebSocket-Extensions| header field or split
  182.            between multiple instances of the |Sec-WebSocket-Extensions|
  183.            header field.
  185.    This completes the server's handshake.  If the server finishes these
  186.    steps without aborting the WebSocket handshake, the server considers
  187.    the WebSocket connection to be established and that the WebSocket
  188.    connection is in the OPEN state.  At this point, the server may begin
  189.    sending (and receiving) data.
RAW Paste Data