Make Content-Length handling strict

[kou]

Content-Length value must have only digits.

See also RFC 9110 Section 8.6:
https://www.rfc-editor.org/rfc/rfc9110.html#section-8.6

Content-Length = 1*DIGIT

The current implementation accepts garbage before/after digits such as abc5 and 5abc.

This rejects these invalid values.

But this accepts same values in one Content-Length

Content-Length: 5, 5

and in multiple Content-Lengthes:

Content-Length: 5
Content-Length: 5

This is for the following part in the RFC:

https://www.rfc-editor.org/rfc/rfc9110.html#section-8.6-13

Likewise, a sender MUST NOT forward a message with a Content-Length
header field value that does not match the ABNF above, with one
exception: a recipient of a Content-Length header field value
consisting of the same decimal value repeated as a comma-separated
list (e.g, "Content-Length: 42, 42") MAY either reject the message
as invalid or replace that invalid field value with a single
instance of the decimal value, since this likely indicates that a
duplicate was generated or combined by an upstream message
processor.

[kou]

We must use self[]= not @headers[]= here because self[]= uses downcase.

[hsbt]

An empty Content-Length field is silently dropped when another field carries a value, so the response is accepted instead of rejected.

Content-Length: 5
Content-Length:
# => content_length returns 5

Content-Length:
# => Net::HTTPHeaderSyntaxError: Content-Length has multiple different values:

"".split(/\s*,\s*/, -1) returns [], not [""], so an empty field contributes no element to lengths. In the first case it vanishes and validation passes. In the second case lengths is empty, lengths.uniq.size != 1 is true for zero elements, and the message reports a duplicate that does not exist. The old code raised wrong Content-Length format there.

[hsbt]

👍