W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2022

Re: Could someone clarify these sentences in HPACK RFC 7541?

From: Jingcheng Zhang <diogin@gmail.com>
Date: Tue, 18 Jan 2022 15:07:51 +0800
Message-ID: <CACE=nTcUSM3Qnem1TX_7Nc=Uo86mOu0KnLtuA5JA3LdqJNzi7A@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: ietf-http-wg@w3.org
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

This archive was generated by hypermail 2.4.0 : Tuesday, 18 January 2022 07:08:15 UTC