Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Server condump
- Input:
- GET / HTTP/1.1
- Host: 127.0.0.1:9090
- User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:12.0) Gecko/20100101 Firefox/
- 12.0
- Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
- Accept-Language: en-us,en;q=0.5
- Accept-Encoding: gzip, deflate
- Connection: keep-alive, Upgrade
- Sec-WebSocket-Version: 13
- Origin: http://127.0.0.1
- Sec-WebSocket-Key: iTAsnxQZ045LBMzPRnlYGg==
- Pragma: no-cache
- Cache-Control: no-cache
- Upgrade: websocket
- Key: iTAsnxQZ045LBMzPRnlYGg==
- Sending Response:
- GET / HTTP/1.1 400 Bad request
- Upgrade: websocket
- Connection: Upgrade
- Sec-WebSocket-Accept: lDvWhu8hXx1WwZQ+pK0bQiugEBY=
- 4.2.2. Sending the Server's Opening Handshake
- When a client establishes a WebSocket connection to a server, the
- server MUST complete the following steps to accept the connection and
- send the server's opening handshake.
- 1. If the connection is happening on an HTTPS (HTTP-over-TLS) port,
- perform a TLS handshake over the connection. If this fails
- (e.g., the client indicated a host name in the extended client
- hello "server_name" extension that the server does not host),
- then close the connection; otherwise, all further communication
- for the connection (including the server's handshake) MUST run
- through the encrypted tunnel [RFC5246].
- 2. The server can perform additional client authentication, for
- example, by returning a 401 status code with the corresponding
- |WWW-Authenticate| header field as described in [RFC2616].
- 3. The server MAY redirect the client using a 3xx status code
- [RFC2616]. Note that this step can happen together with, before,
- or after the optional authentication step described above.
- 4. Establish the following information:
- /origin/
- The |Origin| header field in the client's handshake indicates
- the origin of the script establishing the connection. The
- origin is serialized to ASCII and converted to lowercase. The
- server MAY use this information as part of a determination of
- whether to accept the incoming connection. If the server does
- not validate the origin, it will accept connections from
- anywhere. If the server does not wish to accept this
- connection, it MUST return an appropriate HTTP error code
- (e.g., 403 Forbidden) and abort the WebSocket handshake
- described in this section. For more detail, refer to
- Section 10.
- /key/
- The |Sec-WebSocket-Key| header field in the client's handshake
- includes a base64-encoded value that, if decoded, is 16 bytes
- in length. This (encoded) value is used in the creation of
- the server's handshake to indicate an acceptance of the
- connection. It is not necessary for the server to base64-
- decode the |Sec-WebSocket-Key| value.
- Fette & Melnikov Standards Track [Page 22]
- RFC 6455 The WebSocket Protocol December 2011
- /version/
- The |Sec-WebSocket-Version| header field in the client's
- handshake includes the version of the WebSocket Protocol with
- which the client is attempting to communicate. If this
- version does not match a version understood by the server, the
- server MUST abort the WebSocket handshake described in this
- section and instead send an appropriate HTTP error code (such
- as 426 Upgrade Required) and a |Sec-WebSocket-Version| header
- field indicating the version(s) the server is capable of
- understanding.
- /resource name/
- An identifier for the service provided by the server. If the
- server provides multiple services, then the value should be
- derived from the resource name given in the client's handshake
- in the "Request-URI" [RFC2616] of the GET method. If the
- requested service is not available, the server MUST send an
- appropriate HTTP error code (such as 404 Not Found) and abort
- the WebSocket handshake.
- /subprotocol/
- Either a single value representing the subprotocol the server
- is ready to use or null. The value chosen MUST be derived
- from the client's handshake, specifically by selecting one of
- the values from the |Sec-WebSocket-Protocol| field that the
- server is willing to use for this connection (if any). If the
- client's handshake did not contain such a header field or if
- the server does not agree to any of the client's requested
- subprotocols, the only acceptable value is null. The absence
- of such a field is equivalent to the null value (meaning that
- if the server does not wish to agree to one of the suggested
- subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol|
- header field in its response). The empty string is not the
- same as the null value for these purposes and is not a legal
- value for this field. The ABNF for the value of this header
- field is (token), where the definitions of constructs and
- rules are as given in [RFC2616].
- /extensions/
- A (possibly empty) list representing the protocol-level
- extensions the server is ready to use. If the server supports
- multiple extensions, then the value MUST be derived from the
- client's handshake, specifically by selecting one or more of
- the values from the |Sec-WebSocket-Extensions| field. The
- absence of such a field is equivalent to the null value. The
- empty string is not the same as the null value for these
- Fette & Melnikov Standards Track [Page 23]
- RFC 6455 The WebSocket Protocol December 2011
- purposes. Extensions not listed by the client MUST NOT be
- listed. The method by which these values should be selected
- and interpreted is discussed in Section 9.1.
- 5. If the server chooses to accept the incoming connection, it MUST
- reply with a valid HTTP response indicating the following.
- 1. A Status-Line with a 101 response code as per RFC 2616
- [RFC2616]. Such a response could look like "HTTP/1.1 101
- Switching Protocols".
- 2. An |Upgrade| header field with value "websocket" as per RFC
- 2616 [RFC2616].
- 3. A |Connection| header field with value "Upgrade".
- 4. A |Sec-WebSocket-Accept| header field. The value of this
- header field is constructed by concatenating /key/, defined
- above in step 4 in Section 4.2.2, with the string "258EAFA5-
- E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this
- concatenated value to obtain a 20-byte value and base64-
- encoding (see Section 4 of [RFC4648]) this 20-byte hash.
- The ABNF [RFC2616] of this header field is defined as
- follows:
- Sec-WebSocket-Accept = base64-value-non-empty
- base64-value-non-empty = (1*base64-data [ base64-padding ]) |
- base64-padding
- base64-data = 4base64-character
- base64-padding = (2base64-character "==") |
- (3base64-character "=")
- base64-character = ALPHA | DIGIT | "+" | "/"
- NOTE: As an example, if the value of the |Sec-WebSocket-Key| header
- field in the client's handshake were "dGhlIHNhbXBsZSBub25jZQ==", the
- server would append the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
- to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
- C5AB0DC85B11". The server would then take the SHA-1 hash of this
- string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90
- 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value
- is then base64-encoded, to give the value
- "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned in the
- |Sec-WebSocket-Accept| header field.
- 5. Optionally, a |Sec-WebSocket-Protocol| header field, with a
- value /subprotocol/ as defined in step 4 in Section 4.2.2.
- Fette & Melnikov Standards Track [Page 24]
- RFC 6455 The WebSocket Protocol December 2011
- 6. Optionally, a |Sec-WebSocket-Extensions| header field, with a
- value /extensions/ as defined in step 4 in Section 4.2.2. If
- multiple extensions are to be used, they can all be listed in
- a single |Sec-WebSocket-Extensions| header field or split
- between multiple instances of the |Sec-WebSocket-Extensions|
- header field.
- This completes the server's handshake. If the server finishes these
- steps without aborting the WebSocket handshake, the server considers
- the WebSocket connection to be established and that the WebSocket
- connection is in the OPEN state. At this point, the server may begin
- sending (and receiving) data.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement