I am planning to implement the Websocket protocol and currently learning how handshake headers must be structured. According to this linkhttp://datatracker.ietf.org/doc/rfc6455/?include_text=1To 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.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-95CA-  C5AB0DC85B11.  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.So when I actually decode s3pPLMBiTxaQ9kYGzzhZRbK+xOo= in base64 decoder on decoder, it gives me @:e^qlkWhich I do not think it is going to decrypted into original value using SHA-1 properly. So far, my understanding is 1) Server received Sec-WebSocket-Key value from client and combine that with GUID generated from the serverSo it becomes like:dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B112) then server applies SHA-1 and base64 encoding onto it and the key becomes:s3pPLMBiTxaQ9kYGzzhZRbK+xOo=to send back to the clinet.So in order to turn Websocket-accept value into the original dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11, I need to decode the above value using Base64 and decrypt it with sha-1 and I must receive the original value back. However, when I actually attempt it, it gives me the weird value I have mentioned above. Could you please correct me which part I am doing wrong? Thank you.
Base64 decode and SH1 decryption of Sec-WebSocket-Accept value example from Websocket RFC
javascript;networking;protocol
You're testing the base64_decode incorrectly. It decodes to a series of bytes which are not characters which can be viewed easily. But testing in PHP shows that decoding it with the code$array = unpack(H*, base64_decode(s3pPLMBiTxaQ9kYGzzhZRbK+xOo=));var_dump(str_split($array[1], 2));gives the bytes.  0 => string 'b3' (length=2)  1 => string '7a' (length=2)  2 => string '4f' (length=2)  3 => string '2c' (length=2)  4 => string 'c0' (length=2)  5 => string '62' (length=2)  6 => string '4f' (length=2)  7 => string '16' (length=2)  8 => string '90' (length=2)  9 => string 'f6' (length=2)  10 => string '46' (length=2)  11 => string '06' (length=2)  12 => string 'cf' (length=2)  13 => string '38' (length=2)  14 => string '59' (length=2)  15 => string '45' (length=2)  16 => string 'b2' (length=2)  17 => string 'be' (length=2)  18 => string 'c4' (length=2)  19 => string 'ea' (length=2)As mentioned in chat, you don't need to 'decode' this anywhere, it's just that your server is meant to be generating the correct value from the source values to send back to the client.