Re: [quicwg/base-drafts] Asymmetry in the handling of SETTINGS frame (#1846)

[Mike Bishop <[e-mail]>]

This isn't asymmetrical, actually.  Both client and server MUST know the settings before they can send requests/responses.  It's just that there are two cases, which you're conflating:

- For 1-RTT, the client is required to see the server's (0.5-RTT flight) SETTINGS frame before sending requests, and the server is required to see the client's SETTINGS frame before sending responses.
- For 0-RTT, the client is assuming (and the server is consenting to, by accepting 0-RTT) minimum values for settings remembered from last time, which is what permits it to send without seeing the SETTINGS.  The server still needs the client's SETTINGS, because there is no implicit contract on the client's parameters in 0-RTT.

In HTTP/2, both parties have to tolerate peers having lower values than the defaults: the defaults apply until the real SETTINGS frame is seen and then get revised downward, so you have to tolerate reductions after you've already violated the setting unknowingly.  In the HQ version, there is never a downward revision, only an upward revision, so you eliminate the unknowing violation.  That was the motivation to introduce the restriction.

-- 
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/1846#issuecomment-428307396