Code change:
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. <del> A server that receives a request with a "Client-Cert" or "Client- Cert-Chain" header field value that it considers to be too large can respond with an HTTP 431 status code per RFC6585. </del> 3. <ins> 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using HPACK RFC7541 or QPACK I-D.ietf-quic-qpack) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. 3.2. A server in receipt of a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code per RFC6585.  Due to the typical size of the field values containing certificate data, recipients may need to be configured to allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g. HTTP/2 RFC7540 or HTTP/3 I-D.ietf-quic-http) should account for the additional size of header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. 4. </ins> The header fields described herein enable a TTRP and backend or origin server to function together as though, from the client's perspective, they are a single logical server side deployment of

Related discussion:
text: Document what needs to happen for compression. The Client-Cert field will be largely constant for the same client, so it might be a good candidate for compression. However, with requests through the TTRP potentially coming from multiple clients, the connection to the origin server might get different values over time. Document what needs to happen here: either very large dynamic tables with certificates in them, or no compression for the field and larger requests. You also need to consider the effect on the protocol of very large header blocks. Both HTTP/2 and HTTP/3 have soft limits on the size of header blocks that this might exceed. Servers need to be provisioned to allow for large certificates. cc NAME
Thanks for the feedback Martin. I've read through RFC7541 and some of RFC7540 and I'm honestly still unsure what this draft can or should say about compression. As I understand it, the size of the dynamic table is established between the peers (dynamic table size update and SETTINGSHEADERTABLE_SIZE) of the connection. And the TTRP would decide whether or not to add client certs to the table. Undoubtedly there's a trade off between large dynamic table with certs and no compression for the field with larger requests. But I don't know what's "better" and imagine it will depend on the specifics of the deployment. Although I guess continually adding and evicting certs on a small table would be the worst of both. Are you looking to have that trade off described in something like an implementation/deployment considerations? Or something more or different? And if so, are there some specifics you can suggest or propose? WRT limits and large headers, URL has "A server that receives a request with a Client-Cert header value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of [RFC6585]." Is that wrong? Or insufficient? Or is this another implementation/deployment considerations thing where the draft should mention to readers that they might need to adjust some settings around maxim header sizes? Or something else?
Roughly, I think you could say something like
I think the issue is somewhat different. H2/H3 allow implementations to advertise a limit on the sum of the size of all headers received.