RFC 9110 defines the Content-Length ABNF rule like this:
Content-Length = 1*DIGIT
(i.e. 1 or more ASCII digits)
The same also says this:
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.
Thus, if a proxy receives the following request, it should not be forwarded with the Content-Length header unchanged:
GET / HTTP/1.1\r\n
Host: whatever\r\n
Content-Length: \r\n
\r\n
How should an endpoint server handle such a request? Should it be rejected? If it should instead be accepted, then how should it be interpreted?
I have taken a wide survey of the HTTP ecosystem on this issue, and implementations seem to be varied. I am interested in hearing opinions on both sides of the accept/reject divide.
EDIT: RFC 9112 also says this:
When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed above, the server SHOULD respond with a 400 (Bad Request) response and close the connection.
This statement seems to invalidate the whole ABNF, and justifies accepting empty CL. That said, if matching the grammar is only a soft requirement, what is the point of the standards?