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

[Lucas Pardue <[e-mail]>]

Yes it would be unwise because there's a good enough fall back, use static compression.

Pending priority removal from the spec, the only thing SETTINGS holds is header-related parameters. Removing the QPACK dynamic table aspect from the discussion means that we are discussing only SETTINGS_MAX_HEADER_LIST_SIZE. We discussed the usefulness of that parameter on #2516, with some happy to support its removal; but we decided in London to keep it.

So all we can talk about for SETTINGS is in terms of extensions, known or unknown. Sending SETTINGS isn't blocked on the peer but is that true for how an application acts upon those SETTINGS? E.g. Should a server that implements an extension and advertises it in its SETTINGS block until it receives a SETTINGS from its peer? That depends on the nature of the extension. 

So on this axiom, I'd be happy with text that says an endpoint MUST send SETTINGS before all other activity, along with some guidance in the "Extension to HTTP/3" section that describes the risks in blocking on reception of SETTINGS.

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