- From: Jingcheng Zhang <diogin@gmail.com>
- Date: Tue, 18 Jan 2022 15:07:51 +0800
- To: Martin Thomson <mt@lowentropy.net>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CACE=nTcUSM3Qnem1TX_7Nc=Uo86mOu0KnLtuA5JA3LdqJNzi7A@mail.gmail.com>
Got it. Thanks! On Tue, Jan 18, 2022 at 12:41 PM Martin Thomson <mt@lowentropy.net> wrote: > On Tue, Jan 18, 2022, at 14:41, Jingcheng Zhang wrote: > > I thought the SETTINGS_HEADER_TABLE_SIZE setting follows the same > > design, that is, the receiver of this defined setting changes the > > dynamic table immediately after it receives this defined setting if the > > value is smaller than previous one. So why does it need to send > > additional Dynamic Table Size Update? > > The maximum still takes effect when the setting is acknowledged. However, > we decided that it would be better if the current size of the dynamic table > was always signaled with Dynamic Table Size Update. If we did not require > the instruction, then there would be an implicit dependency on the state of > SETTINGS+ACK frames. A HPACK decoder would then need a second source of > information about the state of the table. > > > 2. Current RFC seems to lack a description on a change to > > SETTINGS_MAX_FRAME_SIZE, especially a reduction on frame size. Should > > it be added to keep it consistent with descriptions of changes to other > > defined settings? > > My opinion is that the general rules cover changes to > SETTINGS_MAX_FRAME_SIZE. That doesn't require special handling - an > endpoint that wants to reduce the value just has to tolerate larger values > until the acknowledgment. > -- Best regards, Jingcheng Zhang Beijing, China
Received on Tuesday, 18 January 2022 07:08:14 UTC