Invalid Content-Type header returns HTTP 500 instead of 400

[Oliver Haas]

#36991 made HttpRequest._set_content_type_params() raise BadRequest for an invalid Content-Type header; before it was LookupError.

But according to the ​docs, the behavior and intention of the change was to my understanding to get a 400 response, but current main still responds with a 500, e.g. just with

curl -i -X POST http://127.0.0.1:8000/ -H "Content-Type: text/plain; charset*=BOGUS''%20"

This isn't really a regression, more like an incomplete fix.

Basically the exceptions are raised when the request is created and not inside the get_response(), so it slips by before the aptly named convert_exception_to_response() is used.

I'm intending to open a pull request shortly after this.

'Disclaimer'
I used Claude Code to investigate this bug. I saw this (super rare) error in our production env, probably coming from a security scanner. Mostly harmless, but also thought I could contribute here with a quick fix.

[Sarah Boyce]

Thank you for the report, replicated
Feel free to submit a PR!

Possible test below

tests/handlers/tests.py

@@ -93 +93 @@
         # Expect "bad request" response
         self.assertEqual(response.status_code, 400)
 
+    def test_invalid_content_type_returns_bad_request(self):
+        environ = self.request_factory.post("/malformed_post/").environ
+        environ["CONTENT_TYPE"] = "text/plain; charset*=BOGUS''%20"
+        handler = WSGIHandler()
+        response = handler(environ, lambda *a, **k: None)
+        self.addCleanup(response.close)
+        self.assertEqual(response.status_code, 400)
+
 
 @override_settings(ROOT_URLCONF="handlers.urls", MIDDLEWARE=[])

[Chiranjibee18]

I have submitted a pull request with the fix and regression test:https://github.com/django/django/pull/22224

[Oliver Haas]

Replying to Chiranjibee18:

I have submitted a pull request with the fix and regression test:https://github.com/django/django/pull/22224

I think this is a correct minimal fix.

Ideally the code surrounding it would be refactored though in the future. asgi and wsgi approach do not really agree here, and sometimes request parsing errors are not raised when parsing the request and just handled later, while other request parsing errors raise.