Re: [quicwg/base-drafts] Default settings in HTTP (#2038)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.

This looks great!!!

I like the PR because the approach provides the most flexibility; a client that wants to wait for SETTINGS can wait. A client that wants to not wait can start sending requests using the default settings parameters, then update as it receives the SETTINGS frame.

Should we state that the QPACK encoder stream MUST NOT be opened if the current value of SETTINGS_HEADER_TABLE_SIZE is zero, and that the decoder stream MUST NOT be opened until the peer opens the encoder stream?

I ask this because avoiding the cost of maintaining unused but open streams would be beneficial for using HTTP/3 on memory constrained devices. I do not think requiring that would be a burden because an endpoint nevertheless needs to wait for the arrival of the SETTINGS frame before starting to send dynamic table entries on the encoder stream. For the decoder stream, implementations can simply create them lazily.



-- 
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/pull/2038#pullrequestreview-177495291