[quicwg/base-drafts] HTTP/3 settings frames and prioritization (#2772)

["Tom D." <[e-mail]>]

My issue is the following: The current HTTP/3 specifications say that a SETTINGS frame must be sent as the first frame of the control stream directly following QUIC connection establishment.

```
While connection-level options pertaining to the core QUIC protocol are set in the initial crypto handshake, HTTP/3-specific settings are conveyed in the SETTINGS frame. 
After the QUIC connection is established, a SETTINGS frame (Section 7.2.5) MUST be sent by each endpoint as the initial frame of their respective HTTP control stream (see Section 6.2.1).
```

Depending on how connection establishment is defined, this could result in some awkward client-sided behavior. There are two ways to interpret connection establishment as far as I can tell:
1. The moment the server has 1-RTT send-keys available (i.e., after Client Hello)
2. On receipt of the client finished TLS packet

In the first case, the server can specify its settings before the client makes its first request. In the second case however, the client can already send its first request before having received the server's settings. To handle this case, the specifications say the following:

```
An HTTP implementation MUST NOT send frames or requests which would be invalid based on its current understanding of the peer’s settings. 
All settings begin at an initial value, and are updated upon receipt of a SETTINGS frame. 
For servers, the initial value of each client setting is the default value.
```

Now say for example that a client wants to use Firefox's prioritization scheme and connection establishment is defined in the second way (receipt of client finished packet). Ideally it would use placeholders to structure the dependency tree, but as it has not yet received a settings frame, it is not allowed to do so (default placeholder count is 0). This gives the client two options from what I can tell: 
1. Wait for the settings frame to arrive (and therefore block, which isn't exactly elegant)
2. Use a fallback prioritization scheme and reprioritize requests later when the settings frame has been received and it allows the placeholders the client wants to use (which we'd also ideally like to avoid).

As neither of these options are preferred, the importance of the definition of connection establishment is highlighted even more. My request is, if a clear answer has already been thought out, to add a more verbose description of what connection establishment actually means in this situation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2772