Add validation for pseudo-headers on requests/responses

[isaacrivriv]

Motivation:
According to the (old) RFC 7540 on Section 8.1.2.1, 'Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests.'

Modifications:
Updated Http2Encoder to check headers while writing for Pseudo-Headers and treat them as invalid requests or response if the Pseudo-Headers are not expected

Result:
After this change, requests/responses with invalid Pseudo-Headers will be treated as malformed and a stream error is thrown

Fixes #13646

[KingMob]

It might also be worth checking to ensure that mandatory pseudo-headers are present. Netty currently checks that the values are correct, but not that the headers themselves are present.

From RFC 9113 § 8.3.1 and 8.3.2:

All HTTP/2 requests MUST include exactly one valid value for the ":method", ":scheme", and ":path" pseudo-header fields, unless they are CONNECT requests. An HTTP request that omits mandatory pseudo-header fields is malformed (Section 8.1.1).

For HTTP/2 responses, a single ":status" pseudo-header field is defined that carries the HTTP status code field (see Section 15 of [HTTP]). This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed (Section 8.1.1).

That would fix part of #13630 (but not all of it)

[mostroverkhov]

headers.names() copies names into new LinkedHashSet - for iteration It is sufficient to use Http2Headers.iterator() which does not do redundant copy (possibly guarded by isEmpty() check returning Collections.emptyIterator())

[isaacrivriv]

Will make the change, thanks for the comment!

[franz1981]

this is super costy: try first to check if the prefix is a pseudoheader one

[isaacrivriv]

The isPseudoHeader call eventually leads down to getPseudoHeaderName which has a check for the prefix so it should be okay.

[franz1981]

Maybe make sense to modify the pseudo header names to have an array/list of all the ones request only/not request only. in order to perform the match upfront and eventually not perform any iteration/match, if not necessary.

[isaacrivriv]

The iteration could be super costly especially with a large number of headers so I agree if we could skip the iteration I would. I'm thinking of an alternative to this by adding flags to the Http2 Header class itself and checking them when passing through the encoder which in my mind should be better.

[isaacrivriv]

Actually on second thought, the request pseudoHeaders are actually always on the front to be iterated so it makes it more efficient to just stop going through the headers once we stop reading pseudoHeaders. I'm making changes to follow this approach.

[normanmaurer]

@isaacrivriv what is the status of this one ?

[isaacrivriv]

I ran into some failures with I believe was the H2 Multiplexer set of tests which I couldn't figure out. I'll try to get back to this next week.

[isaacrivriv]

I pushed some changes which led me to passing all the h2 tests and included some tests to verify the functionality. I did have to disable most of the header validation for the tests since most of them used just empty headers or invalid headers to do a quick test of other functionality. I'm working on another approach that hopefully skips iterating while writing the headers to compare.

[isaacrivriv]

I pushed out changes that should make this more efficient since the pseudo headers go first and there are already checks in place that confirm that custom pseudo headers can't be added as stated by RFC 9113 Section 8.3

Endpoints MUST NOT generate pseudo-header fields other than those defined in this document

The checks should happen pretty quickly. Following the approach in #13603 I also used the validate headers flag from the builders to decide if we would do the check or not.

The only checks that occur in this PR are to verify that request headers don't contain response pseudo headers and response headers don't contain request pseudo headers. I don't check if the required pseudo headers are found according to RFC 9113 Section 8.3.1 so this could be something to further build on this change

All HTTP/2 requests MUST include exactly one valid value for the ":method", ":scheme", and ":path" pseudo-header fields, unless they are CONNECT requests (Section 8.5). An HTTP request that omits mandatory pseudo-header fields is malformed (Section 8.1.1).

And also stated for the response as well

For HTTP/2 responses, a single ":status" pseudo-header field is defined that carries the HTTP status code field (see Section 15 of [HTTP]). This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed (Section 8.1.1).