Re: Clarification of dynamic table size change

[Tatsuhiro Tsujikawa <[e-mail]>]

Hi,

On Tue, Oct 20, 2015 at 1:12 AM, Cory Benfield <[e-mail]> wrote:

>
> > On 19 Oct 2015, at 16:59, Tatsuhiro Tsujikawa <[e-mail]>
> wrote:
> >
> > I can read that dynamic table size update is always necessary as
> acknowledgement of SETTINGS_HEADER_TABLE_SIZE if it is present in SETTINGS.
> > But someone can read in the other way.
>
> Yeah, see, I read it the other way. My reading of section 4.2 of RFC 7541
> emphasises this: “a *change* in the maximum size […] is signalled”. But
> you’re right that it’s ambiguous. In this case, I’d say that an
> implementation MAY emit a dynamic table size update if the size is
> unchanged (because it’s a no-op), but MUST do so if it has changed. For
> implementation simplicity, many implementations will chose to always emit
> that size update, but equally many implementations will not. If we’re
> counting, my own implementation does the same thing as Google’s: see
> here[0].
>
> Specifically, I don’t think the HPACK layer should complain because a
> dynamic table size update was not received when the dynamic table size did
> not change. In this instance I believe nghttp2 is being overly strict about
> the relationship between the HTTP/2 layer and the HPACK layer.
>
>
​Could be.  But I don't think we mixed HTTP/2 layer and HPACK layer.  More
specifically, we input the max header table size to HPACK, and see what it
react to it in this case.  It is specific to HPACK implementation behaviour.

In general, we choose simpler path in HTTP/2​, I mean single execution path
rather than "do this if we have x otherwise do that".  For example, we
require client preface even if we negotiated HTTP/2 over ALPN.
We send HTTP2-Settings in HTTP Upgrade request, but still we need to send
SETTINGS frame in client preface.
Taking into account of this split, it is more natural to always send header
table size update as acknowledgement for SETTINGS_HEADER_TABLE_SIZE.  We
can do more strict validation about the peer; it might forget to implement
it anyway.

Best regards,
Tatsuhiro Tsujikawa




> Cory
>
> [0]: https://github.com/python-hyper/hpack/blob/master/hpack/table.py#L188
>