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

[Kazuho Oku <[e-mail]>]

@lnicco @MikeBishop Thank you for clarifying that we have a restriction for 1-RTT case, client-side.

@MikeBishop 
> Also, because settings are allowed to negotiate non-conformant behavior (and we no longer have a SETTINGS_ACK), in the general case, you can't guarantee that anything received on any other stream actually means what you think it means until you've seen SETTINGS. In the more common case where you don't support any such behavior, of course, this isn't a problem.

If that is the case, shouldn't we better block the client from sending anything (including SETTINGS) until it receives SETTINGS from server sent in 0.5 RTT?

In my view, without such requirement, current design does *not* allow the endpoints to *negotiate* their settings. Rather, it is unilateral declaration of SETTINGS by two parties. Assuming that we are fine with the lock-step approach on exchanging SETTINGS, I think adding one latch that requires the client for server's SETTINGS before sending it's SETTINGS would be fine.

If we have that latch, exchange of SETTINGS becomes a *negotiation*. That would allow us to evolve in various ways, e.g. have a different static table (#1343), or even have a different compression algorithm.

-- 
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-428358560