Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

[Martin Thomson <[e-mail]>]

That seems unwise in the extreme.  SETTINGS was designed to be non-blocking.

The advice here seems simple enough:

1. send SETTINGS always

  corollary (that I didn't think needed to be stated explicitly, but we can do that): don't condition your SETTINGS on the value from your peer
  optional: maybe recommend always sending all non-default settings and not assuming that a peer has saved values

2. don't use a ticket unless you also have SETTINGS

   inference: if you don't, you get vanilla h3 (and Alan will be sad that he spent all that time on QPACK only to have you not use it, you ingrate)

I think that addresses concerns about resumption as well as 0-RTT.  I agree that this is not great from an implementation perspective, but I'm fairly sure that we can all use `&&` in our code.  Async handling for NewSessionTicket will suck for sure, but that's not the worst complication ever.

-- 
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/2945#issuecomment-518915926