Require server to handle Content-Length headers when receiveing HTTP requests

[provinzkraut]

Add a clause in the spec that:

• Requires servers to never read past an announced Content-Length
• Optionally respond with a 400 - Bad Request if the actual length exceeds the announced length

Motivation

Compatibility with the WSGI spec

As ASGI is a self-described "superset of the WSGI format", it should honour WSGIs stipulation around handling Content-Length. PEP 3333 says:

The server is not required to read past the client’s specified Content-Length, and should simulate an end-of-file condition if the application attempts to read past that point. The application should not attempt to read more data than is specified by the CONTENT_LENGTH variable.

The proposed addition would make ASGI compliant with the WSGI specification in this regard, and adding some additional guarantees by changing the server behaviour from should to must.

Confidence for downstream consumers

Currently, ASGI applications can not assume that the Content-Length header reflects the actual content length returned by successive calls to receive(). This means they can only use the Content-Length header as a hint if present, but would need to check its consistency themselves if they want to rely on it.

Compare this PR where such a feature is discussed: https://github.com/encode/starlette/pull/2328/files#r1397168621