Summary

  • A TLS-terminating proxy adds serialized certificate information to the HTTP request sent onward. Acceptance of the original handshake or incoming request does not guarantee room for those added fields.
  • Binary certificate bytes, uncompressed textual field-section bytes and compressed wire or table costs are different measurements. HTTP/2 and HTTP/3 limits do not disappear when compression is effective.
  • Capacity planning must preserve the agreed certificate and chain semantics. Silent omission is not a sound substitute for reserving metadata headroom, and an advertised maximum is not an unconditional acceptance promise.

The request grows after the client has sent it

Consider a hypothetical application behind a reverse proxy. The client completes a mutually authenticated TLS exchange and sends an HTTP request that the proxy is willing to receive. Before forwarding it, the proxy attaches the certificate information its backend uses. The downstream receiver now confronts a larger collection of HTTP fields than the client submitted. It may decline to process that collection even though nothing in the imagined sequence requires a failed outer handshake.

This is an illustration, not a reported incident or a test we have run. Its significance is architectural: two admissions occurred against different representations. The first transport accepted certificate material in its TLS exchange. The next application transport must carry certificate information alongside the request's existing fields. Treating the first event as proof of sufficient downstream capacity skips the step where the message changed.

RFC9440, published in July 2023 as an IETF Informational RFC, describes this transition rather than promising to abolish it. Its purpose is to codify a common way for a TLS-terminating reverse proxy to convey client certificate information to an origin application. The document is not an Internet Standards Track specification, and its interoperability benefit does not establish any particular implementation's performance or safe operating limit.

The certificate in question belongs to the originating client's mutually authenticated connection with the terminating proxy. Additional internal hops do not turn the fields into descriptions of whichever certificate happened to secure the last hop. The intended mechanism allows the backend to use that original information while the deployment operates as a logical server from the client's perspective. It does not make the original client a trusted author of the forwarding fields.

For this article, the central question is narrower than whether that path is trustworthy. A trustworthy path is necessary, but it can still be too small for the representation it has agreed to carry. Once the proxy adds metadata, who has reserved the space, in what units, and under which certificate-presence policy? Those are capacity decisions, not a second way of naming successful authentication.

Three sizes hiding behind one word

RFC9440 carries an end-entity certificate in Client-Cert and may carry its validation chain in Client-Cert-Chain. The certificates are DER-encoded X.509 objects represented as Structured Fields Byte Sequences. Their textual form uses base64 between colons, without embedded line breaks or spaces. The field is therefore not a raw binary certificate dropped unchanged into HTTP.

That conversion supplies the first distinction. The binary object's size and the length of its serialized value differ. Base64 groups binary input into an expanded textual representation; delimiters, field names and list syntax also occupy space. The relationship can be calculated from a chosen encoding without measuring a production system. Such arithmetic tells an operator what representation must be budgeted, not what size every origin is obliged to accept.

A second distinction appears when HTTP field compression is involved. A compressed field block is decoded into textual field names and values. The value still contains the base64 representation at that stage; it has not magically become the smaller DER object simply because the transport's compression decoder finished. Counting the certificate after binary decoding answers a different question from counting the field section after HTTP decompression.

The third distinction concerns transmission and state. A repeated value may be inexpensive to represent on the wire if a compression table can refer to an earlier entry. That does not make its uncompressed field-section contribution disappear. Conversely, a field sent as a literal need not occupy a retained dynamic-table entry, but it still arrives as a field whose name and value the receiver must handle. A graph of wire traffic, a table-capacity setting and an application field-size limit describe separate constraints.

Collapsing all three into “certificate size” makes coordination harder. The certificate owner may discuss binary objects, the proxy owner may describe encoded headers, and the transport team may show compressed bandwidth. Each measurement can be accurate while the participants remain in disagreement about the message the backend actually receives.

A parser's capability is not a receiver's promise

Structured Fields provides a useful example of the distinction. RFC8941, and its successor RFC9651, require Byte Sequence parsers to support at least 16,384 octets after binary decoding. This is a capability requirement for that data type. It does not compel an HTTP server to process every request containing such an item, plus a chain, cookies and other fields, regardless of its limits.

Nor can the minimum simply be copied into a textual-header allowance. The HTTP representation contains base64 rather than decoded binary, and the complete field section includes more than one value. An implementation can possess the required parser capability while enforcing a smaller operational envelope for a particular request. Equally, allowing a large field section says nothing about whether an embedded object is a valid certificate or acceptable to the application's policy.

HTTP itself supplies no predefined universal maximum for a field line, field value or whole section. RFC9110 instead recognizes receivers' limits and requires an appropriate client-error response when request fields are larger than a server wishes to process. Its warning against simply ignoring those fields concerns request-smuggling exposure. It is not an invitation to turn a missing authentication input into the normal remedy for an oversized request.

The transport-specific settings make the units more explicit. HTTP/2 uses SETTINGS_MAX_HEADER_LIST_SIZE. Under RFC9113, this advisory value concerns the uncompressed name and value lengths, with 32 octets of accounting overhead for each field line. The receiver may enforce a lower limit for a given request. The initial setting is unlimited, but that starting value is not evidence of an unlimited application, gateway or route.

HTTP/3 uses the differently named SETTINGS_MAX_FIELD_SECTION_SIZE. RFC9114 likewise counts uncompressed field names and values with 32 bytes per field. A peer receiving the parameter should avoid sending a section above it. Crucially, the specification explains that every implementation along an intermediary path applies its own limit. Remaining below one announced value does not guarantee acceptance farther along.

The names are not interchangeable, and neither describes a compressed frame's length. A message can occupy comparatively few transmitted bytes yet exceed an uncompressed field-section allowance. It can also fall within a transport setting but encounter a lower application limit. The useful operational question is therefore not “Which maximum did we see?” but “Which receiver, representation and request does that maximum cover?”

Compression cannot repay a field-section debt

RFC9440 flags a particular workload: a compression-capable connection between proxy and origin multiplexing requests from different clients. Large, varying certificate values can make compression less efficient. That conditional observation should not be inflated into a claim that every certificate-forwarding deployment has a compression problem. It is a reason to examine the workload, not a benchmark result.

The document describes two possible responses. An origin might enlarge its dynamic table. A proxy that finds the origin's table insufficient might prefer to send the certificate field as a literal instead of entering it into that table. One spends more retained state in pursuit of reuse; the other may avoid retaining entries that are poor candidates for reuse. Neither is prescribed as the universal winning configuration.

HPACK makes table accounting another distinct object. RFC7541 sizes an entry from its name and value lengths before Huffman encoding, plus 32 octets. The permitted maximum is determined by the surrounding protocol, and an encoder may use less capacity. Enlarging that ceiling changes a memory/reuse opportunity. It does not raise a server's independent willingness to accept a field section.

QPACK likewise has a decoder-bounded maximum dynamic-table capacity, communicated through SETTINGS_QPACK_MAX_TABLE_CAPACITY. RFC9204 prohibits insertions when that maximum is zero. This parameter is separate from HTTP/3's maximum field-section size. An operator discussing one cannot assume a corresponding change in the other, and this article does not claim that QPACK invariably blocks certificate-bearing requests.

The practical trade-off is workload-specific. A stable recurring certificate value and a stream of different values do not offer the same reuse pattern. Multiple clients sharing an internal connection need not be represented by one uniform credential. Decisions about table occupancy, literal transmission and field-section admission should therefore remain distinct even when the same team owns all of them.

There is also a boundary to what compression evidence proves. Fewer wire bytes are not proof of enough field-section headroom, and retained entries are not a response cache or an authentication database. Using a compression statistic to authorize a larger admitted message would confuse an observed cost with a policy decision about a different resource.

Reserve room before adding information

The intermediary is where these budgets meet. A client's original request may approach the size the proxy advertises. When the proxy subsequently adds certificate data, the backend receives a section with additional occupancy. Copying the backend's allowance upstream unchanged can leave no room for the very metadata the proxy promised to supply.

RFC9440 recommends that intermediaries advertising maximum acceptable header sizes account for their additions by presenting clients with a sufficiently smaller value. This is a headroom recommendation, not a universal subtraction constant or a newly invented mandatory setting. The amount depends on what the intermediary actually adds and what the selected downstream receiver can handle.

A useful local agreement identifies those additions, the counting representation and the relevant receiver. It also identifies changes that can invalidate the estimate: a different validation chain, another route, a new request field or an altered presence policy. These are proposed planning questions, not evidence of a measured migration. An agreement about one ordinary path should not be described as proof every alternative path fits.

Certificate chains complicate a simplistic size fix. Client-Cert is a singleton end-entity certificate field. Client-Cert-Chain is an optional list, excludes that end-entity certificate and follows TLS certificate ordering. The optional nature of the chain does not mean an application that has agreed to receive it can lose it silently without a semantic change.

RFC9440 allows omission of a root only when the target origin is known to possess that trust anchor. That condition is not satisfied merely because an omitted object would save space. Similarly, a chain may be split across multiple field instances, potentially benefiting compression, while HTTP/2 and HTTP/3 field-list accounting also charges names and per-field overhead for the resulting lines. Representation choices can move costs rather than eliminate them.

A refusal should not quietly rewrite the application

RFC6585 defines 431 for an unwilling receiver facing an oversized set of request fields or a single excessive field. It allows resubmission after reducing those fields and recommends identifying the offending field when one is responsible. But support for 431 is optional; the specification also recognizes that an attacked server may drop connections or take other steps. No single status is guaranteed by the certificate-forwarding mechanism.

The client may not control the addition that made its downstream request too large. A retry that reduces ordinary client fields could help in an illustrative case, but repeated unchanged retries do not create room. Removing certificate information instead could change the backend's authentication input. A smaller request and a semantically equivalent request are not the same achievement.

Absence may be entirely legitimate in an application using another authentication arrangement. The point is not to impose a universal denial whenever a certificate field is missing. It is to state the arrangement deliberately rather than let a capacity workaround invent a new one. A receiver's behavior for missing evidence belongs to its agreed application policy, not to the compression encoder's convenience.

Resumption exposes a related continuity issue. RFC9440 notes that some TLS implementations cannot retain certificate information for resumed sessions. For implementations unable to provide consistent fields, it recommends either disabling resumption for certificate connections or initially omitting a field that might later become unavailable. These are conditional design alternatives, not a claim that resumption always loses certificates or instructions to change any running service.

Finally, response caching must be kept apart from field compression. When Client-Cert selects a response, RFC9440 requires an uncacheable response or selective reuse keyed by that same field value. A terminating proxy encountering certificate fields in Vary should transform that value to * to prevent user-agent caching. Separately, 431 responses must not be cached. None of those rules is fulfilled merely by enlarging an HPACK or QPACK table.

Trust, field presence, capacity and response selection remain distinct obligations. Incoming certificate-field injection must be prevented and the forwarding path protected; a request that fits does not relax those requirements. The capacity problem adds a local operating contract to the trusted deployment. It does not replace the deployment's security boundary.

Sources and limits of the argument

This analysis uses published specifications and Lu Heng's coordination principles, not deployment telemetry. The scenarios are hypothetical and unexecuted. No vendor default, safe universal size, observed outage, throughput gain or completed negative test is claimed. Normative requirements are distinguished from conditional recommendations and editorial planning implications.