HTTP2 SETTINGS_MAX_HEADER_LIST_SIZE not properly used

[isaacrivriv]

While working on Netty, I noticed a couple of failing tests related to HTTP2 and GRPC that seem to be behaving correctly according to the logic of the tests. One such test was the HTTP2 test testDynamicTableSize sending a settings frame with a maxHeaderListSize of 128 and expecting a response back.

According to the HTTP2 RFC 9113 section 6.5.2,

SETTINGS_MAX_HEADER_LIST_SIZE (0x06):
This advisory setting informs a peer of the maximum field section size that the sender is prepared to accept, in units of octets. The value is based on the uncompressed size of field lines, including the length of the name and value in units of octets plus an overhead of 32 octets for each field line.

For any given request, a lower limit than what is advertised MAY be enforced. The initial value of this setting is unlimited.

In Legacy, the tests expect an ack of the settings frame and a response to the request because the maxHeaderListSize setting is valid. This response however, exceeds the established setting and with Netty the test fail with a RESET FRAME sent back as would be expected. After some investigation, I can see the setting being parsed in Legacy but never used in the H2 logic to verify that the request/response are valid according to the setting.

In section 6.5 of RFC 9113 it states,

A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection. Implementations MUST support all of the settings defined by this specification.

We should work on adding the logic for this setting to be able to properly support it and match the RFC.

[pnicolucci]

This could certainly be seen as a behavior change in our H2 implementation. We should determine how we can disable and enable this setting in Netty. The Netty implementation should initially have the same behavior as our current legacy channel framework implementation. We should then discuss this at the POC to determine if this is an acceptable change in behavior. If it is we could make it the default behavior, otherwise we would need a configuration to enable the Netty behavior and have the legacy channel framework behavior as the default behavior.

[isaacrivriv]

Sounds good, I already saw an API that stops Netty from enforcing this setting in the HTTP2 Codec builder we are using just need to check if we can get this exposed so that we can use it on our side without any overlays. See here

[pnicolucci]

Netty issue: https://github.com/netty/netty/issues/14281

[pnicolucci]

@isaacrivriv can this one be closed out as resolved now? Do you have a PR we can link?

[isaacrivriv]

This was merged in Netty in https://github.com/netty/netty/pull/14282 and was added in our Netty transport branch in commit 5199c3f3764f815040a41cf80e1f495b134dfd0e however, legacy does not include this functionality. I'm okay with closing this issue if we create a new one to follow up on the legacy implementation to implement this.