Skip to content

HTTPCORE-801: Use long for unsigned 32-bit HTTP/2 values - #723

Closed
arturobernalg wants to merge 1 commit into
apache:masterfrom
arturobernalg:HTTPCORE-801
Closed

arturobernalg wants to merge 1 commit into
apache:masterfrom
arturobernalg:HTTPCORE-801

Conversation

@arturobernalg

Copy link
Copy Markdown
Member

Use long to represent HTTP/2 settings values and error codes defined as unsigned 32-bit integers.

Keep narrower protocol values such as initial window size and maximum frame size as int, and preserve the 32-bit wire representation when encoding and decoding frames.

This also preserves the full range of unknown HTTP/2 error codes and settings values without interpreting values with the high bit set as negative Java integers.

Use long for HTTP/2 settings values and error codes defined as
unsigned 32-bit integers.
@arturobernalg
arturobernalg requested a review from ok2c October 7, 2026 11:49
Comment thread pom.xml
<exclude>@org.apache.hc.core5.annotation.Internal</exclude>
<exclude>org.apache.hc.core5.testing.reactive.ReactiveTestUtils</exclude>
<exclude>org.apache.hc.core5.testing.framework.*</exclude>
<!-- HTTPCORE-801: uint32 HTTP/2 values returned as long -->

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arturobernalg I do not think this is a good idea. We should not do that until 6.0. I am not in favor of this change. Quite strongly.

@arturobernalg

Copy link
Copy Markdown
Member Author

@ok2c
Understood. I agree this is too disruptive for the 5.x API.
Let's defer HTTPCORE-801 to 6.0 and address the unsigned 32-bit representation there without compatibility constraints.

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.

2 participants