How to adjust HPACK dynamic table?
lemur117 at protonmail.com
Sat Dec 19 19:18:51 UTC 2020
On 12/18/20 6:00 AM, nginx-request at nginx.org wrote:
> Re: How to adjust HPACK dynamic table?
Sorry I'm not yet familiar with how to write a follow-up on the mailing list, including the inline text, but thank you Maxim for your response to my inquiry. Please see below for a follow-up question.
On Thu, Dec 17, 2020 at 05:01:54AM +0000, Jon Carmicheal wrote:
> I would like to disable the caching of headers in the dynamic
> table of the HTTP/2 HPACK compression algorithm described in RFC
> 7541. I have defined my nginx server with
> listen 8080
> and I've confirmed that the HPACK algorithm is working as
> expected with Huffman encoding, static header table indexing,
> and dynamic header table indexing. But I haven't been able to
> disable the dynamic table.
You cannot disable dynamic table support in nginx. As an HPACK
decoder, nginx supports dynamic table of up to 4096 octets (the
default for SETTINGS_HEADER_TABLE_SIZE in HTTP/2).
> RFC 7541 mentions in "Section 4.2. Maximum Table Size" the
> ability of an HTTP/2 node to "clear entries from the dynamic
> table by setting a maximum size of 0, which can subsequently be
> restored." Is that a feature supported by nginx? Can I disable
> the dynamic table entirely so that no header fields are cached?
> And can I arbitrarily send a flush request so that all entries
> are evicted and then the dynamic table size is restored? If so,
Yes, it is supported. The "how" is specified in the section "6.3.
Dynamic Table Size Update" of the same RFC
How is this accomplished in nginx? Can I configure the nginx server so that it sets the size of the dynamic table to 0 immediately when an HTTP/2 session is initiated?
> I've been trying to play with "http2_max_field_size" and
> "http2_max_header_size" in the server configuration file as
> described in
> . But I
> don't think those are the right parameters. When I set either of
> them to zero, it makes the server return an error when a header
> is sent.
These are unrelated parameters. They set size limits on
compressed individual header fields and total length of all
uncompressed headers, respectively, so nginx will reject attempts
to use larger headers.
Thanks, this was my assumption.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx