Django 4.2a1 Breaks serverless WSGI lambda build : 'NoneType' object has no attribute 'read'

[advl]

Hello !

I have a minimal Django application deployed on Lambda using Zappa. I have managed to get a working setup using the Django and Zappa defaults for version 3.2, and 4.1.7. All requests loads as expected.

However, on upgrade to 4.2a1, the lambda endpoint returns a 500 error :

When accessing directly the endpoint, the stack trace displays the following :

"{'message': 'An uncaught exception happened while servicing this request. You can investigate this with the `zappa tail` command.', 'traceback': ['Traceback (most recent call last):\\n', '  File \"/var/task/handler.py\", line 591, in handler\\n    with Response.from_app(self.wsgi_app, environ) as response:\\n', '  File \"/var/task/werkzeug/wrappers/response.py\", line 291, in from_app\\n    return cls(*run_wsgi_app(app, environ, buffered))\\n', '  File \"/var/task/werkzeug/test.py\", line 1243, in run_wsgi_app\\n    app_rv = app(environ, start_response)\\n', '  File \"/var/task/zappa/middleware.py\", line 58, in __call__\\n    response = self.application(environ, encode_response)\\n', '  File \"/var/task/django/core/handlers/wsgi.py\", line 133, in __call__\\n    request = self.request_class(environ)\\n', '  File \"/var/task/django/core/handlers/wsgi.py\", line 81, in __init__\\n    self._stream = LimitedStream(self.environ[\"wsgi.input\"], content_length)\\n', '  File \"/var/task/django/core/handlers/wsgi.py\", line 24, in __init__\\n    self._read = stream.read\\n', \"AttributeError: 'NoneType' object has no attribute 'read'\\n\"]}"

And from the lambda logs on CloudWatch (equivalent to zappa tail)

`2023-02-17T22:25:42.303+01:00 : 'NoneType' object has no attribute 'read'`

As zappa seems to be a bit stale, I am wondering whether it would be preferable to keep the interface working on django's side longer ? Or is the more compliant and strict wsgi the way to go for django, even if this might introduce breaking changes for people using this setup ?

(I categorized this bug as "Core (Other)" after hesitating to put it in the category HTTP handling.)