23.2 What changed in handlers, requests, URLs and views

Django’s middleware under ASGI

Before 6.2 Django’s middleware classes inherited async_capable = True from MiddlewareMixin, so under ASGI a chain of them ran in the mixin’s async mode: the chain stayed on the event loop, and each process_request and process_response went to a thread and back. Since 6.2 each that has either hook sets it to false, and BaseHandler.load_middleware runs them synchronously: together they make one call into the request’s thread, and the centre of the chain one call back to the loop. The release notes give the repeated switching as the reason, and allow that a deployment with much concurrent I/O outside the ORM may prefer it to a thread held for each request. Sync and async in one chain tells the rule and draws both arrangements.

The mixin’s own flag is still true, so a project’s middleware built on it can still run asynchronously, and a subclass of Django’s that sets the flag back can run in async mode again. But the chain runs a layer synchronously whenever the layer inside it is synchronous and it can be, so one of Django’s middleware listed after a project’s puts the project’s in sync mode too. RemoteUserMiddleware, not built on the mixin, declares both flags; LoginRequiredMiddleware and XViewMiddleware have neither hook and keep the mixin’s.

MiddlewareMixin itself moved in 6.2, from django.utils.deprecation to django.middleware. The old module answers the old import through its module-level __getattr__, which warns with RemovedInDjango2029Warning and returns the same class (__getattr__; What still warns: the deprecations and the releases that end them).

Error responses on the request’s thread

Under ASGI the wrapper convert_exception_to_response puts around an asynchronous layer, the centre of the chain or a middleware in async mode, is a coroutine, which runs response_for_exception, error view and all, through sync_to_async when the layer raises. Since 6.2 it passes thread_sensitive=True, so the error view runs on the request’s own thread, where before it ran on a shared pool. The release notes’ reason is the database: a connection belongs to the thread that opened it, and the change lets close_old_connections, which runs on the request’s thread as the request starts and ends, manage the connections a handler404 or a handler500 uses. How an exception becomes a response tells the conversion, and Sync and async in one chain the request’s thread.

The ASGI request: a disconnect and several cookies

Since 5.0 an "http.disconnect" that comes before the response is made is handled, so that a view can clean up. At this commit ASGIHandler.handle hears it while it reads the body, and then runs a listener beside the chain and the sending of the response in one asyncio.TaskGroup. A disconnect cancels the work: a coroutine view is cancelled where it awaits, and can clean up, while synchronous code already running in the request’s thread runs to its end (ASGIHandler.handle; The two entry points).

Since 6.0 the several "cookie" headers that HTTP/2 allows are joined with a semicolon and a space into one "HTTP_COOKIE", where any other repeated header is joined with commas (ASGIRequest.__init__; Making the request: WSGIRequest and ASGIRequest).

Decorators around a coroutine view

The handler decides how to call a view by asking whether it is a coroutine function, and it asks the outermost decorator’s wrapper: a wrapper written with def makes an async def view look synchronous. The view decorators did not support coroutine views before 5.0. Since then each decorator of django/views/decorators/ but sensitive_variables, and each made from a middleware, picks when it is applied a def wrapper or an async def one that awaits the view; since 5.2 method_decorator marks its replacement as a coroutine function when the method is one. sensitive_variables takes a coroutine by not wrapping it: it records the names under the function’s file and first line, where the error reporter looks. Asynchronous views tells what the handler’s test needs.

JsonResponse and its safe argument

JsonResponse used to refuse anything but a dictionary unless it was given safe=False, a guard against an attack on a JSON array through JavaScript’s array prototype that, the release notes say, ECMAScript 5 closed. Since 6.2 the argument’s default is None, read as false, so a list is serialised without it. Passing it any value but None warns with RemovedInDjango2029Warning, and safe=True still raises TypeError for a value that is not a dictionary (JsonResponse.__init__; The response object).

The multipart parser’s Base64

Since 6.1 MultiPartParser.parse decodes a part sent with a "base64" transfer encoding through base64.b64decode with validate=True, so a character outside the Base64 alphabet makes the data invalid (in a file, white space is removed first); before, the notes say, invalid data could be silently ignored or give empty values (MultiPartParser.parse; Multipart parsing and upload handlers). They say it now raises MultiPartParserError. At this commit that holds for a file, which the handler answers with a 400; a field that does not decode is kept as sent.

# base64_parts.py at this commit: one part of a multipart body, with Content-Transfer-Encoding: base64
a field, 'aGFyYm91cg=='    POST {'berth': ['harbour']}
a field, 'aGFy!Ym91cg=='   POST {'berth': ['aGFy!Ym91cg==']}
a file,  'aGFyYm91cg=='    FILES {'log': b'harbour'}
a file,  'aGFy!Ym91cg=='   raises MultiPartParserError: Could not decode base64 data.

The smaller changes