Invalid `Content-Length` values should be rejected

[kenballus]

When cpp-httplib receives a request with an invalid Content-Length header value, it treats it as equivalent to a value of 0 instead of rejecting the request with a 400.

For example, the following request should be rejected with status 400, but is instead accepted:

POST / HTTP/1.1\r\n
Host: whatever\r\n
Content-Length: x\r\n
\r\n

This is caused by the strtoull call on httplib.h:2022. The HTTP RFCs require stricter parsing than strtoull enforces by default.

[yhirose]

@kenballus thanks for the report.

The HTTP RFCs require stricter parsing than strtoull enforces by default.

Where can we see the information?

[kenballus]

From RFC 9112:

If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error, unless the field value can be successfully parsed as a comma-separated list (Section 5.6.1 of [HTTP]), all values in the list are valid, and all values in the list are the same (in which case, the message is processed with that single value used as the Content-Length field value). If the unrecoverable error is in a request message, the server MUST respond with a 400 (Bad Request) status code and then close the connection.

RFC 9110 gives the following ABNF rule for Content-Length values:

Content-Length = 1*DIGIT

[kenballus]

If you want to use strtoull, you need to check the endptr argument to make sure that the entire length of the data was processed and contained no invalid characters.

You also need to check the beginning of the value to make sure that - and + characters are not there, since strtoull accepts them.

[yhirose]

@kenballus thanks for the detailed helpful informaiton!