RFR: 8354276: Strict HTTP header validation [v4]

[Jaikiran Pai]

On Thu, 10 Apr 2025 16:35:01 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeliński has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix whitespace
>  - Use ProtocolException for malformed headers

src/java.net.http/share/classes/jdk/internal/net/http/common/HeaderDecoder.java line 34:

> 32: 
> 33:     public HeaderDecoder() {
> 34:         super(Context.REQUEST);

It feels a bit odd that a header "decoder" is being used in the context of a request. I then looked at the references of this class and I see that the only place this gets used/instantiated is in the `PushPromiseDecoder` and it then makes sense why the context used here is `REQUEST`. 

Do you think it would be better if we changed this `HeaderDecoder` constructor to accept a `Context` param and then have `PushPromiseDecoder` pass it the `Context.REQUEST`? That way it's a bit more clear at the use site, in PushPromiseDecoder, why `Context.REQUEST` gets used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2063756842