Code change:
The client certificate is be placed in the "Client-Cert" header field of the dispatched request as defined in header. <del> Any occurrence of the "Client-Cert" header in the original </del> <ins> Any occurrence of the "Client-Cert" header field in the original </ins> incoming request MUST be removed or overwritten before forwarding the request.  An incoming request that has a "Client-Cert" header <del> MAY be rejected with an HTTP 400 response. </del> <ins> field MAY be rejected with an HTTP 400 response. </ins> Requests made over a TLS connection where the use of client certificate authentication was not negotiated MUST be sanitized by removing any and all occurrences "Client-Cert" header field prior to dispatching the request to the backend server. <del> Backend origin servers may then use the "Client-Cert" header of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby </del> <ins> Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby </ins> presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- <del> Cert" header to requests, or modify an existing "Client-Cert" header. Similarly, clients MUST NOT employ the "Client-Cert" header in requests. </del> <ins> Cert" header field to requests, or modify an existing "Client-Cert" header field.  Similarly, clients MUST NOT employ the "Client-Cert" header field in requests. </ins> <del> 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. </del> <ins> A server that receives a request with a "Client-Cert" header field value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of RFC6585. </ins> 3. <del> The header described herein enable a TTRP and backend or origin </del> <ins> The header field described herein enable a TTRP and backend or origin </ins> server to function together as though, from the client's perspective, they are a single logical server side deployment of HTTPS over a mutually-authenticated TLS connection.  Use of the "Client-Cert" <del> header outside that intended use case, however, may undermine the protections afforded by TLS client certificate authentication. </del> <ins> header field outside that intended use case, however, may undermine the protections afforded by TLS client certificate authentication. </ins> Therefore steps MUST be taken to prevent unintended use, both in <del> sending the header and in relying on its value. </del> <ins> sending the header field and in relying on its value. </ins> <del> Producing and consuming the "Client-Cert" header SHOULD be a </del> <ins> Producing and consuming the "Client-Cert" header field SHOULD be a </ins> configurable option, respectively, in a TTRP and backend server (or individual application in that server).  The default configuration <del> for both should be to not use the "Client-Cert" header thus requiring an "opt-in" to the functionality. </del> <ins> for both should be to not use the "Client-Cert" header field thus requiring an "opt-in" to the functionality. </ins> <del> In order to prevent header injection, backend servers MUST only accept the "Client-Cert" header from a trusted TTRP (or other proxy in a trusted path from the TTRP).  A TTRP MUST sanitize the incoming </del> <ins> In order to prevent field injection, backend servers MUST only accept the "Client-Cert" header field from a trusted TTRP (or other proxy in a trusted path from the TTRP).  A TTRP MUST sanitize the incoming </ins> request before forwarding it on by removing or overwriting any <del> existing instances of the header.  Otherwise arbitrary clients can control the header value as seen and used by the backend server.  It is important to note that neglecting to prevent header injection does </del> <ins> existing instances of the field.  Otherwise arbitrary clients can control the field value as seen and used by the backend server.  It is important to note that neglecting to prevent field injection does </ins> not "fail safe" in that the nominal functionality will still work as expected even when malicious actions are possible.  As such, extra <del> care is recommended in ensuring that proper header sanitation is in </del> <ins> care is recommended in ensuring that proper field sanitation is in </ins> place. The communication between a TTRP and backend server needs to be

Related discussion:
text: This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)