Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move validation of connection headers in HTTP/2 back to HpackDecoder #12982

Merged
merged 1 commit into from
Nov 10, 2022

Conversation

idelpivnitskiy
Copy link
Member

Motivation:

#12755 added validation for presence of connection-related headers while HpackDecoder decodes the incoming frame. Then #12832 moved this validation from HpackDecoder to DefaultHttp2Headers. As the result, existing use-case that could use DefaultHttp2Headers for HTTP/2 and HTTP/1.X broke when users add any of the mentioned prohibited headers. The HTTP/1.X to HTTP/2 translation logic usually has sanitization process that removes connection-related headers. It's enough to run this validation only for incoming messages and we should preserve backward compatibility for 4.1.

Modifications:

  • Move isConnectionHeader and te validations from DefaultHttp2Headers back to HpackDecoder;
  • Add tests to verify HpackDecoder fails incoming headers as expected;
  • Add tests to verify mentioned headers can be added to DefaultHttp2Headers;

Result:

Backward compatibility is preserved, while validation for connection-related headers is done in HpackDecoder.

Backport of #12975.

Motivation:

netty#12755 added validation for presence of connection-related headers while
`HpackDecoder` decodes the incoming frame. Then netty#12832 moved this
validation from `HpackDecoder` to `DefaultHttp2Headers`. As the result,
existing use-case that could use `DefaultHttp2Headers` for HTTP/2 and
HTTP/1.X broke when users add  any of the mentioned prohibited headers.
The HTTP/1.X to HTTP/2 translation logic usually has sanitization
process that removes connection-related headers. It's enough to run this
validation only for incoming messages and we should preserve backward
compatibility for 4.1.

Modifications:

- Move `isConnectionHeader` and `te` validations from
`DefaultHttp2Headers` back to `HpackDecoder`;
- Add tests to verify `HpackDecoder` fails incoming headers as
expected;
- Add tests to verify mentioned headers can be added to
`DefaultHttp2Headers`;

Result:

Backward compatibility is preserved, while validation for
connection-related headers is done in `HpackDecoder`.
@idelpivnitskiy
Copy link
Member Author

idelpivnitskiy commented Nov 10, 2022

@chrisvest do you know why java17-graal pipelined failed 2 times in a row at "check_build_result.sh" task? how can I check the build-leak.output file?

@normanmaurer normanmaurer merged commit c4f4bed into netty:main Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants