HTTP2::Connection::Configuration

An additional defense-in-depth cap on the number of fields a single decoded section may contain. Neither RFC 9113 nor RFC 7541 impose any field-count limit of their own — only the byte-size bounds (max_compressed_field_section_size, max_decoded_field_section_size) are protocol-adjacent. A too-low count limit rejects legitimate, if unusual, requests (large cookie jars, tracing/baggage headers, etc.) that were never actually a resource risk.

This getter's default does not newly exceed what the byte-size cap already permits: the HPack field-section-size accounting this library uses charges name.bytesize + value.bytesize + 32 per field (RFC 7541's dynamic-table-size formula, reused here for the section limit), so even a maximally degenerate all-empty-valued section already fits roughly 65_536 / 32 = 2_048 fields under the ~64 KiB max_decoded_field_section_size default regardless of this setting — the byte cap alone already lets a peer reach that many fields, as long as each one stays near the fixed 32-byte floor; it takes many SMALL fields to get there, not a few large-valued ones. This getter's default (1_024) stays comfortably under that implicit ~2_048 ceiling, not above it — it does not, by itself, keep a large field count out; it only avoids rejecting a legitimate, unusually field-heavy request while staying within what the byte cap alone already allows.