Optimize Http 2 header validation #5072
Description
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
- vertx convert to lower case (checking for upper case chars) via
- 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
- 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).