RFC 6455 Quiz

Q1: Should the client enter the OPEN state?

Multiple Choice

A client offered no extensions. The server replies 101 with correct Upgrade, Connection, and Sec-WebSocket-Accept fields, but also selects an extension in Sec-WebSocket-Extensions.

A. Enter OPEN because a valid Sec-WebSocket-Accept authorizes any server extension B. Enter OPEN but ignore the extension because unknown response fields have no effect C. Fail the WebSocket connection because the server selected an unoffered extension D. Retry only the frame that first uses the extension after entering OPEN

**Explanation:** A: Sec-WebSocket-Accept validates the handshake response derived from the client's key; it does not authorize unsolicited extensions. B: Sec-WebSocket-Extensions is a defined negotiation field, not an ignorable unknown field in this context. C: RFC 6455 Section 4.1 step 5 requires the client to fail when the response selects an extension that the client did not offer. D: The invalid negotiation prevents the connection from entering the data-framing phase.

Q2: What may the server conclude from Origin?

Multiple Choice

A privileged endpoint accepts `Origin: https://trusted.example` as its only client credential. Browser scripts and autonomous A2A clients can both connect to the endpoint.

A. The value authenticates every client because RFC 6455 requires all senders to protect it B. It can support browser-origin policy, but non-browser identity needs a separate authenticated mechanism C. Its absence authenticates a non-browser client because only browsers are able to send the field D. TLS makes the client-supplied value an identity claim bound to the application account

**Explanation:** A: Section 4.1 requires Origin from browser clients but permits it from suitable non-browser clients; the field is not a universal credential. B: Sections 4.2.2 and 10.2 use Origin to decide which script origins may connect. RFC 6455 explicitly notes that non-browser clients can send a fabricated Origin; authentication and authorization remain separate. C: A non-browser client may include Origin, so presence or absence does not authenticate its type or identity. D: TLS protects transport and authenticates the TLS peer according to its configuration; it does not convert arbitrary request metadata into application identity.

Q3: How must the server handle this frame?

Multiple Choice

After a valid wss handshake, a client sends an otherwise well-formed text frame with MASK=0. The implementation accepts it because TLS already protects confidentiality.

A. Accept it because client masking is optional on an encrypted connection B. Accept it only when the payload contains no credentials or executable text C. Mask the frame at the server and continue processing the recovered payload D. Close the connection; client-to-server frames must be masked even over TLS

**Explanation:** A: RFC 6455 Section 5.1 says masking applies whether or not WebSocket runs over TLS. B: The requirement depends on frame direction, not application payload sensitivity. C: A missing client mask is a protocol error; the server cannot repair it by inventing a masking key. D: Section 5.1 requires the server to close upon an unmasked client frame and permits status code 1002. Masking is not a substitute for TLS encryption.

Q4: What should the receiver do with the Ping?

Multiple Choice

A large text message is arriving in fragments. Between continuation frames, a valid Ping frame arrives. The receiver buffers it until the text message is complete.

A. Handle the Ping during reassembly because control frames may appear between fragments B. Treat the Ping as the final fragment because it interrupts the continuation sequence C. Fail the connection because no frame may appear inside a fragmented message D. Append the Ping payload to the text message and acknowledge it after UTF-8 validation

**Explanation:** A: Sections 5.4 and 5.5 allow control frames in the middle of a fragmented message and require endpoints to handle them. A Ping generally receives a Pong under Section 5.5.2. B: Continuation and Ping have different opcodes; Ping does not terminate the data message. C: Other data messages normally cannot be interleaved, but control frames are the explicit exception. D: Control payload is not part of the fragmented application's message payload.

Q5: May the intermediary re-fragment the message?

Multiple Choice

A proxy observed the handshake but does not implement a negotiated WebSocket extension. To reduce buffering, it plans to coalesce and split the connection's data-message fragments.

A. Yes, because frame boundaries never have semantics under any extension B. Yes, if each resulting frame is at most 125 bytes long C. No; it must not change fragmentation without understanding negotiated extension semantics D. No, because intermediaries may never change fragmentation on any WebSocket connection

**Explanation:** A: Section 5.4 says extensions can assign meaning to Extension data across fragments. B: The 125-byte limit applies to control frames; it neither authorizes nor governs re-fragmenting data messages. C: Section 5.4 prohibits an intermediary from changing fragmentation when extensions were negotiated and it does not understand their semantics. D: Re-fragmentation can be allowed when no extensions were negotiated, or when the intermediary saw and understands all relevant extension semantics.

Q6: What does the successful handshake prove?

Multiple Choice

An A2A server completes a valid wss handshake and selects `Sec-WebSocket-Protocol: agent-admin`. It then authorizes destructive admin commands without checking any credential or grant.

A. It proves the client owns the admin identity because subprotocol selection authenticates its name B. It establishes WebSocket and the selected protocol, but admin authority still needs independent verification C. It proves authorization only when Sec-WebSocket-Accept was computed from a fresh client key D. It proves authorization whenever TLS protects the channel and the server certificate is valid

**Explanation:** A: Sec-WebSocket-Protocol negotiates application protocol use; it is not a client-identity proof. B: RFC 6455 Sections 4 and 11.3.4 establish the connection and subprotocol selection. Client authentication may be added during the handshake, but grant verification and command authorization are responsibilities of the composed application design. C: Sec-WebSocket-Accept prevents an accidental non-WebSocket response from satisfying the client validation; it is not an authorization credential. D: Ordinary server-authenticated TLS protects the channel and identifies the server, not the client's admin entitlement.

The WebSocket Protocol

References (URLs)

Q1: Should the client enter the OPEN state?

Q2: What may the server conclude from Origin?

Q3: How must the server handle this frame?

Q4: What should the receiver do with the Ping?

Q5: May the intermediary re-fragment the message?

Q6: What does the successful handshake prove?