- From: Martin Thomson <mt@lowentropy.net>
- Date: Tue, 18 Jan 2022 15:41:22 +1100
- To: "Jingcheng Zhang" <diogin@gmail.com>
- Cc: ietf-http-wg@w3.org
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.
Received on Tuesday, 18 January 2022 04:41:55 UTC