ToppyMicroServices

RFC 8441 Quiz

Bootstrapping WebSockets with HTTP/2

πŸ‡ΊπŸ‡Έ πŸ‡―πŸ‡΅
0 / 0

Primary reference

These questions separate connection-scoped negotiation, request construction, WebSocket handshake mapping, stream lifecycle, and intermediary behavior. Section numbers refer to RFC 8441.

Q1: In HTTP/2, WebSockets are bootstrapped primarily using

Multiple Choice
RFC 8441 defines an extended form of CONNECT that creates the WebSocket on one HTTP/2 stream. The request carries a `:protocol` pseudo-header so that the stream's application protocol is explicit. This is different from the connection-wide HTTP/1.1 `Upgrade` exchange. DNS service discovery can locate a service, but it does not establish the HTTP/2 stream or its WebSocket semantics.

Q2: What does using WebSockets over HTTP/2 avoid compared to the HTTP/1.1 upgrade approach

Multiple Choice

A client needs three simultaneous WebSockets and ordinary HTTP requests to the same origin. The deployment criterion is transport-connection reuse, not a change to WebSocket framing or security policy.

Each RFC 8441 WebSocket is associated with an HTTP/2 stream, and multiple streams can coexist on one transport connection. A separate TCP connection per WebSocket is therefore not inherent in this bootstrap model. Multiplexing does not remove transport-security requirements, HTTP setup semantics, or WebSocket framing after the response succeeds. It changes how connections are shared, not what those other layers guarantee.

Q3: Which pseudo-header set correctly requests the WebSocket stream?

Multiple Choice

After receiving the server's opt-in, a client opens wss://agent.example/events over HTTP/2.

A: Section 5 replaces the RFC 6455 GET bootstrap with CONNECT. B: `:protocol` names the tunneled application protocol, not HTTP/2. C: Section 4 requires `:scheme` and `:path` whenever `:protocol` is present. D: This includes CONNECT, the registered `websocket` token, the HTTPS mapping for `wss`, the target path, and the authority.

Q4: Which are still relevant for WebSocket semantics when using HTTP/2 bootstrapping (select all)

Multi-Select

A review claims that a successful extended CONNECT replaces every RFC 6455 and application-layer check. Select the responsibilities that still remain.

RFC 8441 changes the HTTP bootstrap, not the WebSocket application protocol. After a successful response, WebSocket framing and opcode rules still govern the stream; browser Origin validation and application authentication and authorization also remain separate responsibilities. The HTTP/1.1 `Connection` header is not carried into this HTTP/2 exchange. Treating the new bootstrap as an automatic security or authorization mechanism would cross protocol-layer boundaries.

Q5: A proxy only supports HTTP/2 and blocks Upgrade. What is a practical consequence for WebSockets

Multiple Choice

A deployment can reach an origin only through an HTTP/2 hop. The reviewer must choose a bootstrap that the peer actually advertised.

Blocking HTTP/1.1 `Upgrade` does not establish whether RFC 8441 is available. The client must separately determine whether its HTTP/2 peer advertised extended CONNECT support. If so, it can use that bootstrap; otherwise it needs another supported route or must fail the attempt. An ordinary GET does not create WebSocket framing semantics, and HTTP/1.1 `Connection` and `Upgrade` fields cannot be transplanted into an HTTP/2 stream.

Q6: May the client now send extended CONNECT?

Multiple Choice

On one HTTP/2 connection, the client sends SETTINGS_ENABLE_CONNECT_PROTOCOL=1 to the server, but the server has not sent that setting. The client treats its own advertised value as mutual opt-in and wants to open an extended CONNECT stream.

A: Sending the setting advertises a capability to the peer; it does not grant the sender permission. B: Section 3 permits a client to create new extended-CONNECT streams upon receiving value 1, while receipt by a server has no impact. C: The registered initial value is 0. D: RFC 8441 defines this use after server opt-in. The client must wait for the server's setting on this connection.

Q7: Which relay decision is supported by RFC 8441

Multiple Choice

An A2A relay advertises extended CONNECT support to its client. The relay's separate HTTP/2 connection to the origin has not advertised that support. It must decide how to handle the client's WebSocket request.

C is the defensible review result. `SETTINGS_ENABLE_CONNECT_PROTOCOL` is an opt-in by a peer on a particular HTTP/2 connection. Under RFC 8441 Section 3, the relay cannot send `:protocol` on its upstream connection until that upstream peer has advertised support. Sections 4 and 5 define the extended CONNECT request and its WebSocket mapping; an ordinary GET and a generic successful response do not create equivalent semantics. The relay may use another upstream mechanism that the origin actually supports, but the client-facing setting does not authorize or describe that separate hop. Section 7 discusses intermediary use without turning one connection's setting into a route-wide capability.

Q8: Is this target scheme correct for the requested WebSocket URI?

Multiple Choice

A client bootstraps ws://agent.example/events but sends an extended CONNECT request with :scheme=https because the existing HTTP/2 connection uses TLS.

A: Section 5 derives the target scheme from the WebSocket URI, not merely from an implementation preference. B: `ws` maps to `http` and `wss` maps to `https`. C: Section 4 requires `:scheme` when `:protocol` is present. D: `ws` is not the HTTP target-scheme value used by this mapping. The separate security requirements for the HTTP/2 connection still apply.

Q9: Which handshake correction follows RFC 8441?

Multiple Choice

An HTTP/1.1 adapter copies Connection, Upgrade, Sec-WebSocket-Key, Origin, Sec-WebSocket-Version, and Sec-WebSocket-Protocol into an extended CONNECT request.

A: RFC 8441 changes specific opening-handshake fields. B: Connection and Upgrade MUST NOT appear in this HTTP/2 request, while Origin and several Sec-WebSocket fields remain applicable. C: Section 5 says Key/Accept processing is superseded by `:protocol`. D: This preserves the fields RFC 8441 carries forward and removes the HTTP/1.1-only switch and nonce exchange; HTTP/2 field names are lowercase on the wire.

Q10: How should the HTTP/2 stream close after an orderly WebSocket shutdown?

Multiple Choice

The peers have completed their WebSocket closing exchange. The implementation now needs the HTTP/2 analogue of an orderly TCP-level close rather than an exception.

A: Section 5 maps orderly TCP-level closure to HTTP/2 `END_STREAM`. B: `RST_STREAM` with `CANCEL` represents reset exceptions. C: A connection-wide GOAWAY has a broader scope than this one stream. D: HTTP/2 does not use the HTTP/1.1 101 bootstrap, and status is not the stream-close mechanism after the protocol is open.

Q11: Which request should the client send first to this HTTP forward proxy?

Multiple Choice

A client speaks HTTP/2 to a forward proxy and wants a WebSocket connection to an origin through that proxy. The client has not yet created a tunnel to the origin.

A: Section 7 does not redefine the forward proxy as the WebSocket service. B: HTTP/1.1 connection fields cannot be sent on the HTTP/2 hop. C: RFC 8441 says to use traditional CONNECT, without `:protocol`, to tunnel through an HTTP forward proxy; the HTTP version negotiated through that tunnel then determines the WebSocket bootstrap. D: Intermediary use does not waive the negotiation rules.

Q12: What failure should a non-supporting peer produce?

Multiple Choice

Before receiving SETTINGS_ENABLE_CONNECT_PROTOCOL=1, a client sends a CONNECT request with :protocol=websocket. The peer does not implement RFC 8441.

A: Ignoring an unknown pseudo-header would silently change CONNECT semantics. B: Section 3 explains that use before opt-in is detected by a non-supporting peer as a malformed request and produces a stream error. C: The cited failure scope is the stream, not an unconditional connection-wide failure. D: No automatic downgrade or translation rule is defined.