hjava / myblog Goto Github PK

原文7页至第九页
两句 Sec-WebSocket-Protocol: chat 之间的翻译丢失

Sec-WebSocket-Protocol: chat

中间翻译缺失

服务端也可以设置cookie相关字段来设置cookie相关属性，具体文档见[RFC6265][9]。

缺少内容如下

The |Origin| header field [RFC6454] is used to protect against
unauthorized cross-origin use of a WebSocket server by scripts using
the WebSocket API in a web browser. The server is informed of the
script origin generating the WebSocket connection request. If the
server does not wish to accept connections from this origin, it can
choose to reject the connection by sending an appropriate HTTP error
code. This header field is sent by browser clients; for non-browser
clients, this header field may be sent if it makes sense in the
context of those clients.
Finally, the server has to prove to the client that it received the
client’s WebSocket handshake, so that the server doesn’t accept
connections that are not WebSocket connections. This prevents an
attacker from tricking a WebSocket server by sending it carefully
crafted packets using XMLHttpRequest [XMLHttpRequest] or a form
submission.
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
piece of information comes from the |Sec-WebSocket-Key| header field
in the client handshake:
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
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
any leading and trailing whitespace) and concatenate this with the
Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-
95CA-C5AB0DC85B11" in string form, which is unlikely to be used by
network endpoints that do not understand the WebSocket Protocol. A
SHA-1 hash (160 bits) [FIPS.180-3], base64-encoded (see Section 4 of
[RFC4648]), of this concatenation is then returned in the server’s
handshake.
Fette & Melnikov Standards Track [Page 7]
RFC 6455 The WebSocket Protocol December 2011
Concretely, if as in the example above, the |Sec-WebSocket-Key|
header field had the value "dGhlIHNhbXBsZSBub25jZQ==", the server
would concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CAC5AB0DC85B11".
The server would then take the SHA-1 hash of this,
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 (see Section 4 of [RFC4648]), to give the value
"s3pPLMBiTxaQ9kYGzzhZRbK+xOo=". This value would then be echoed in
the |Sec-WebSocket-Accept| header field.
The handshake from the server is much simpler than the client
handshake. The first line is an HTTP Status-Line, with the status
code 101:
HTTP/1.1 101 Switching Protocols
Any status code other than 101 indicates that the WebSocket handshake
has not completed and that the semantics of HTTP still apply. The
headers follow the status code.
The |Connection| and |Upgrade| header fields complete the HTTP
Upgrade. The |Sec-WebSocket-Accept| header field indicates whether
the server is willing to accept the connection. If present, this
header field must include a hash of the client’s nonce sent in
|Sec-WebSocket-Key| along with a predefined GUID. Any other value
must not be interpreted as an acceptance of the connection by the
server.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
These fields are checked by the WebSocket client for scripted pages.
If the |Sec-WebSocket-Accept| value does not match the expected
value, if the header field is missing, or if the HTTP status code is
not 101, the connection will not be established, and WebSocket frames
will not be sent.
Option fields can also be included. In this version of the protocol,
the main option field is |Sec-WebSocket-Protocol|, which indicates
the subprotocol that the server has selected. WebSocket clients
verify that the server included one of the values that was specified
in the WebSocket client’s handshake. A server that speaks multiple
subprotocols has to make sure it selects one based on the client’s
handshake and specifies it in its handshake.