René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Websocket协议第一章的翻译部分缺失","articleBody":"原文7页至第九页\r\n两句 Sec-WebSocket-Protocol: chat 之间的翻译丢失\r\n\r\n\u003e\r\n\u003e\r\n\u003e```http\r\n\u003eSec-WebSocket-Protocol: chat\r\n\u003e```\r\n\u003e ~中间翻译缺失~\r\n\u003e\r\n\u003e服务端也可以设置cookie相关字段来设置cookie相关属性，具体文档见[RFC6265][9]。\r\n\r\n缺少内容如下  \r\n\r\n\u003eThe |Origin| header field [RFC6454] is used to protect against\r\nunauthorized cross-origin use of a WebSocket server by scripts using\r\nthe WebSocket API in a web browser. The server is informed of the\r\nscript origin generating the WebSocket connection request. If the\r\nserver does not wish to accept connections from this origin, it can\r\nchoose to reject the connection by sending an appropriate HTTP error\r\ncode. This header field is sent by browser clients; for non-browser\r\nclients, this header field may be sent if it makes sense in the\r\ncontext of those clients.\r\nFinally, the server has to prove to the client that it received the\r\nclient’s WebSocket handshake, so that the server doesn’t accept\r\nconnections that are not WebSocket connections. This prevents an\r\nattacker from tricking a WebSocket server by sending it carefully\r\ncrafted packets using XMLHttpRequest [XMLHttpRequest] or a form\r\nsubmission.\r\nTo prove that the handshake was received, the server has to take two\r\npieces of information and combine them to form a response. The first\r\npiece of information comes from the |Sec-WebSocket-Key| header field\r\nin the client handshake:\r\nSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\r\nFor this header field, the server has to take the value (as present\r\nin the header field, e.g., the base64-encoded [RFC4648] version minus\r\nany leading and trailing whitespace) and concatenate this with the\r\nGlobally Unique Identifier (GUID, [RFC4122]) \"258EAFA5-E914-47DA-\r\n95CA-C5AB0DC85B11\" in string form, which is unlikely to be used by\r\nnetwork endpoints that do not understand the WebSocket Protocol. A\r\nSHA-1 hash (160 bits) [FIPS.180-3], base64-encoded (see Section 4 of\r\n[RFC4648]), of this concatenation is then returned in the server’s\r\nhandshake.\r\nFette \u0026 Melnikov Standards Track [Page 7]\r\nRFC 6455 The WebSocket Protocol December 2011\r\nConcretely, if as in the example above, the |Sec-WebSocket-Key|\r\nheader field had the value \"dGhlIHNhbXBsZSBub25jZQ==\", the server\r\nwould concatenate the string \"258EAFA5-E914-47DA-95CA-C5AB0DC85B11\"\r\nto form the string \"dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CAC5AB0DC85B11\".\r\nThe server would then take the SHA-1 hash of this,\r\ngiving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6\r\n0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is\r\nthen base64-encoded (see Section 4 of [RFC4648]), to give the value\r\n\"s3pPLMBiTxaQ9kYGzzhZRbK+xOo=\". This value would then be echoed in\r\nthe |Sec-WebSocket-Accept| header field.\r\nThe handshake from the server is much simpler than the client\r\nhandshake. The first line is an HTTP Status-Line, with the status\r\ncode 101:\r\nHTTP/1.1 101 Switching Protocols\r\nAny status code other than 101 indicates that the WebSocket handshake\r\nhas not completed and that the semantics of HTTP still apply. The\r\nheaders follow the status code.\r\nThe |Connection| and |Upgrade| header fields complete the HTTP\r\nUpgrade. The |Sec-WebSocket-Accept| header field indicates whether\r\nthe server is willing to accept the connection. If present, this\r\nheader field must include a hash of the client’s nonce sent in\r\n|Sec-WebSocket-Key| along with a predefined GUID. Any other value\r\nmust not be interpreted as an acceptance of the connection by the\r\nserver.\r\nHTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=\r\nThese fields are checked by the WebSocket client for scripted pages.\r\nIf the |Sec-WebSocket-Accept| value does not match the expected\r\nvalue, if the header field is missing, or if the HTTP status code is\r\nnot 101, the connection will not be established, and WebSocket frames\r\nwill not be sent.\r\nOption fields can also be included. In this version of the protocol,\r\nthe main option field is |Sec-WebSocket-Protocol|, which indicates\r\nthe subprotocol that the server has selected. WebSocket clients\r\nverify that the server included one of the values that was specified\r\nin the WebSocket client’s handshake. A server that speaks multiple\r\nsubprotocols has to make sure it selects one based on the client’s\r\nhandshake and specifies it in its handshake.\r\n\u003e","author":{"url":"https://github.com/peanut996","@type":"Person","name":"peanut996"},"datePublished":"2021-03-18T14:40:51.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/3/myBlog/issues/3"}