On Thu, 10 Apr 2025 16:35:01 GMT, Daniel Jeliński <[email protected]> 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
