Optimize Http 2 header validation

[franz1981]

While inspecting few benchmark this behaviour popup in the HTTP 2 server response handling:

It shows that we do perform few validations around header names, which could be improved or merged (if proves to be beneficial, in the common case things are right).

The existing process work like this;

for header names:

• vertx validate against no ctrl char presence and no ASCII chars via

  vert.x/src/main/java/io/vertx/core/http/impl/HttpUtils.java

  Line 907 in 67ba713

  private static void validateHeaderName(AsciiString value) {

• vertx convert to lower case (checking for upper case chars) via

  vert.x/src/main/java/io/vertx/core/http/impl/HttpUtils.java

  Line 708 in 67ba713

  public static CharSequence toLowerCase(CharSequence sequence) {

• netty validate against upper case chars (which sounds useless here, given that we always send lowercase ones!) and known pseudo-headers, if present, via https://github.com/netty/netty/blob/b1947417b7444326965086b951b75f0128cf7085/codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2Headers.java#L44

for header values:

• vertx validate the value chars with a state machine at

  vert.x/src/main/java/io/vertx/core/http/impl/HttpUtils.java

  Line 805 in 67ba713

  public static void validateHeaderValue(CharSequence seq) {

• netty doesn't validate the header value (!?), and point to https://github.com/netty/netty/blob/b1947417b7444326965086b951b75f0128cf7085/codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2Headers.java#L177-L183

Additionally, related header names, the RFC report at https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2

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

which means that the vertx validation against control character is just too much, and could be dropped.

Re header values, instead, it seems that the validation should follow https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 (which I have yet to interpret).