Correct handling of unsigned HTTP/2 SETTINGS values

[arturobernalg]

RFC 9113 defines SETTINGS values as unsigned 32-bit integers. Values with the high bit set are currently read as negative Java int values and rejected for SETTINGS_HEADER_TABLE_SIZE, SETTINGS_MAX_CONCURRENT_STREAMS, and SETTINGS_MAX_HEADER_LIST_SIZE.

Accept the full unsigned wire range for these settings and bound values above Integer.MAX_VALUE to the internal H2Config representation.

SETTINGS_INITIAL_WINDOW_SIZE is intentionally unchanged: values above 2^31-1 continue to produce FLOW_CONTROL_ERROR. SETTINGS_MAX_FRAME_SIZE also retains its RFC-defined range.

RFC 9113 §2.2, §6.5.1 and §6.5.2.

[ok2c]

@arturobernalg I am honestly not sure I understand the problem you are trying to solve here. What is the problem with the setting value being represented by signed int? What is important that for any kind of arithmetic operations it need to be converted to long with Integer#toUnsignedLong

[arturobernalg]

@arturobernalg I am honestly not sure I understand the problem you are trying to solve here. What is the problem with the setting value being represented by signed int? What is important that for any kind of arithmetic operations it need to be converted to long with Integer#toUnsignedLong

@ok2c I conflated the signed representation with the unsigned interpretation; I’ll keep the raw 32-bit value as int and only use Integer.toUnsignedLong where numeric comparison or arithmetic is required.

[ok2c]

@arturobernalg Exactly! Looks good now.
Please cherry-pick to 5.4.x

[arturobernalg]

@arturobernalg Exactly! Looks good now. Please cherry-pick to 5.4.x

@ok2c done