Issue summary
=============

Tomcat does not follows HTTP/2.0 header name specification : Header names should be US-ASCII encoded but Tomcat : 
- does not check their encoding, 
- allows non US-ASCII encoded
- corrupts non US-ASCII characters by suffixing them with "0xff", example : "0xf0" -> "0xf0 0xff"

Expected behaviour would be : to reject the HTTP/2.0 request as ill-formatted with a HTTP 400 error code.

The specifications
==================

HTTP/2.0
--------

The HTTP/2.0 specification (https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2) says: 
> Just as in HTTP/1.x, header field names are strings of ASCII
> characters that are compared in a case-insensitive fashion.  However,
> header field names MUST be converted to lowercase prior to their
> encoding in HTTP/2.  A request or response containing uppercase
> header field names MUST be treated as malformed (Section 8.1.2.6).

HTTP/1.1
--------

The HTTP/1.1 specification () says : 
> A recipient MUST parse an HTTP message as a sequence of octets in an
> encoding that is a superset of US-ASCII [USASCII].  Parsing an HTTP
> message as a stream of Unicode characters, without regard for the
> specific encoding, creates security vulnerabilities due to the
> varying ways that string processing libraries handle invalid
> multibyte character sequences that contain the octet LF (%x0A).

HPACK
-----

HPACK specification (https://www.rfc-editor.org/rfc/rfc7541.html#section-1.1) says:
> The format defined in this specification treats a list of header
> fields as an ordered collection of name-value pairs that can include
> duplicate pairs.  Names and values are considered to be opaque
> sequences of octets, and the order of header fields is preserved
> after being compressed and decompressed.


Problem description
===================

Tomcat does not reject non-ascii HTTP/2.0 header names, and its HPACK implementation casts the received bytes into chars so that "0xf0" becomes "0xf0 0xff".
It looks like the HPACK algorithm corrupts the header name, and the HTTP/2.0 implementation is then not able to reject this invalid header value (an US-ASCII character is coded with 7 bits, so the first bit MUST be always 0 and obviously "0xf0" has its first bit to 1).

As seen in the previous parts, HPACK algorithm should treat its input as "opaque sequence of octets" and thus should not try to convert them to String directly without knowing their encoding.
Then the HTTP/2.0 implementation should verify that the header names bytes are using only 7 bits (and thus can be safely decoded as ASCII characters).


HTTP/1.1 comparison
===================

Tomcat handles an invalid HTTP/1.1 header correctly, returning a HTTP 400 with this message : "The HTTP header line [0xf0: aa] does not conform to RFC 7230 and has been ignored."


Comparison with other products
==============================

- Netty (tested with 4.1.72) handles it badly too, but the header name "0xf0" is corrupted into "0x00 0xf0" (which is different from what tomcat does : "0xf0 0xff")

Reproducer
==========
- A fresh install of Tomcat (tested with 9 but I guess it will work out with any version of tomcat handling HTTP/2.0)
- the HTTP/2.0 connector configured (`<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />`)
- A simple servlet
- run this command : `$ curl -v http://localhost:8080/static --http2-prior-knowledge -H "😱: aa"`
The request should be rejected with HTTP 400 error because the header name is not US-ASCII encoded.