RFC behavior :

RFC7540 Section 8.1.2.3 : "All HTTP/2 requests MUST include exactly one
valid value for the ":method", ":scheme", and ":path" pseudo-header field,
unless it is a CONNECT request. An HTTP request that omits mandatory
pseudo-header fields is malformed."
RFC7540 Section 8.1.2.6 "Malformed requests or responses that are
detected MUST be treated as a stream error (Section 5.4.2) of type
PROTOCOL_ERROR"
RFC7540 Section 5.4.2 : "An endpoint that detects a stream error sends a
RST_STREAM frame (Section 6.4) that contains the stream identifier of the
stream where the error occurred. The RST_STREAM frame includes an error code
that indicates the type of error."

Actaul Issue - NRF is our network function.

Empty Path:
NRF does not reset the stream when :path pseudo-header field is empty
(without /).
See: 221003-114918_SBA_conformance_pseudoHeadersEmptyPath_172.19.124.pcap

Invalid Content-Length:
NRF sends RST_STREAM with CANCEL reason instead of PROTOCOL_ERROR when
content-length header is no correct for sent data.
See:
221003-114925_SBA_conformance_forbiddenHeadersContentLength_172.19.124.pcap

Invalid Connection-Specific header fields.
RFC7540 Section 8.1.2.2 "Connection-Specific Header Fields"
https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2.2
Noted: Only valid connection-specific header field is "te" and must have
value of "trailers"

NRF does not reset stream when receiving a te header with a value other than
"trailers"
See:
221003-114929_SBA_conformance_forbiddenHeadersTE_172.19.124.pcap

NRF does not reset stream when receiving a request with other
connection-specific header fields.
See:
221003-114932_SBA_conformance_forbiddenHeadersTransferEncoding_172.19.124.pcap
for "transfer-encoding" and
221003-114939_SBA_conformance_forbiddenHeadersKeepAlive_172.19.124.pcap for
"keep-alive"

Netty version Used : 1.0.24

Java version used : 17

Need to know whether Netty follow RFC 7540 and when the compliance will be available.