On 5/1/25 1:40 AM, Willy Tarreau wrote: > Hi, > > On Thu, May 01, 2025 at 01:08:22AM -0400, Demi Marie Obenour wrote: >> I noticed that if HAProxy receives a message containing \x01 in a >> field value, it will happily forward that message. This appears >> to be permitted by RFC9113 and RFC9114. However, it might cause >> a problem if the message is a response, the response is sent to >> the client over HTTP/3, and the client uses nghttp3. nghttp3 will >> silently discard the field, causing HAProxy and the client to >> disagree on whether the field exists. >> >> Is this a serious concern, or is it considered too theoretical to >> matter? From my reading of >> https://github.com/ngtcp2/nghttp3/discussions/346, >> it seems that the nghttp3 maintainer considers this to be working >> as intended (a valid decision). Is there anything that should be >> be done on the HAProxy side, or is HAProxy thinking that a header >> exists when a client thinks it does not expected behavior? > > When H2 begun, some people saw a great opportunity in its ability > to be fully binary-transparent, while others (like us) dealing with > intermediaries saw a big danger in it. From what I remember (but I > could be wrong, I'd need to recheck), the spec only requires that > chars are filtered when converting from H2 to H1. And IIRC in the > end only CR, LF and NUL are forbidden in header values in H2, as > a protective measure for H2 to H1 translation, while HPACK takes > care of permitting absolutely everything. > > The thing is that full H2 applications are explicitly permitted > to rely on this. For example you could imagine sending payload's > SHA256 digests directly in a header, escaping NUL with \0, LF > with \n, CR with \r and '\' with '\\' an keep it compact like > this. So while we have to perform the cleanup for H2,H3 -> H1, > we cannot afford to be excessive and go beyond the spec where > applications expect it to work as permitted by the spec.
Which specification are you referring to? RFC9110 limits the allowed characters in an HTTP field value to 0x9, 0x20 ... 0x7E, and 0x80 ... 0xFF, with the additional requirement that a field cannot start or end with 0x9 or 0x20. RFC9112 (HTTP/1.1), RFC9113 (HTTP/2), and RFC9114 (HTTP/3) all refer to RFC9110 for permitted field values. As far as I can tell, the list of permitted characters has not changed since RFC2068 (January 1997). -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
