parse Content-Length as digits with surrounding whitespace only (#1221)

[pjfanning]

Backport of #1221 (cherry pick 5bdfd6d) to 1.4.x.

Motivation

ContentLengthParser skips whitespace anywhere in the field value:

if (DIGIT(c)) { ... } else if (WSP(c)) recurse(ix + 1, result)

So Content-Length: 1 2 is read as 12, Content-Length: 5 5 as 55, and an empty Content-Length: as 0. The field value is 1*DIGIT surrounded by optional whitespace (RFC 9110, section 8.6 and RFC 9112, section 5). This line dates back to the original Akka HTTP code, so 1.4.x is affected exactly as main was — it is not a regression introduced on main.

The other ways two implementations could disagree about a body length are already closed here — two Content-Length headers with different values are rejected, Transfer-Encoding accepts only a single chunked, and chunked together with a Content-Length is rejected — which is what makes this one worth tightening: it is the remaining case where pekko-http reads a length that a proxy or another server in the request path reads differently, or rejects.

Modification

Skip whitespace before and after the digits, require at least one digit, and end the value at the first non-digit.

This PR also brings SpecializedHeaderValueParsers up to date with the overflow fix from #1049, which landed on main but was never backported. #1221 rewrites the same lines, so the two changes cannot be separated cleanly; rather than cherry pick a partial version of #1221, the whole file is brought to parity with main and #1049's test is backported alongside it.

1.4.x currently checks for overflow with if (result < 0) after the fact, which misses values that wrap back to a positive Long:

Value	1.4.x today	with this PR
92233720368547758080	rejected (already covered by a test)	rejected
18446744073709551617	parsed as 1	rejected
184467440737095516160	parsed as 0	rejected

The replacement checks result > (Long.MaxValue - digit) / 10 before each multiply, so overflow is caught on the digit that would cause it.

Result

A value with whitespace between digits, or with no digit at all, is rejected with the same "Illegal `Content-Length` header value" error that other malformed values already produce. Leading and trailing whitespace still parse as before. A value that overflows Long is rejected with the existing "must not exceed 63-bit integer range" error in the cases listed above that previously slipped through.

This rejects three inputs that were accepted before: whitespace inside the digits, an empty value that used to be read as 0, and an overflowing value that wrapped back to a positive Long. All are malformed, but it is a behaviour change for anyone who was relying on the lenient reading.

After this PR http-core/src/main/scala/org/apache/pekko/http/impl/engine/parsing/SpecializedHeaderValueParsers.scala and http-core/src/test/scala/org/apache/pekko/http/impl/engine/parsing/ContentLengthHeaderParserSpec.scala are byte-identical to main.

No MiMa exclude is needed — SpecializedHeaderValueParsers is @InternalApi private[parsing] and only method bodies change. #1049's num-overflow.excludes covers its HTTP/2 and Timestamp changes, which are not part of this backport.

Tests

• From Parse Content-Length as digits with surrounding whitespace only #1221, in RequestParserSpec: one test for whitespace inside the value and one for an empty value; both fail without the change. Leading whitespace stays covered by the existing Content-length: 17 tests, so the accepted cases are pinned too.
• From Fix integer/long overflow in content-length parsing, timestamp ordering, and HTTP/2 flow control #1049, in ContentLengthHeaderParserSpec: 18446744073709551634 (~2^64+18, wraps to 18 in a signed Long), which fails without the overflow hunk. This is the only test main has for that fix and it was the missing coverage for the overflow change riding along here.