django-request-response-lifecycle

The Django Request-Response Lifecycle is the sequence of events and component interactions that occur from the moment a web server receives an HTTP request to the moment it sends an HTTP response back to the client.

It is the path a request takes through the Django framework. Understanding this lifecycle is crucial for debugging and knowing where to intercept or modify requests and responses (e.g., using middleware).

1. The web server (WSGI/ASGI) receives an HTTP request and passes it to Django.
2. Request passes through the Request Middleware layer.
3. The URL Dispatcher matches the requested path to a view.
4. Request passes through the View Middleware layer.
5. The View function/class is executed, optionally interacting with Models and Templates.
6. The View returns an HttpResponse.
7. Response passes back through the Response Middleware layer.
8. The server sends the response to the browser.

graph TD
  A[Client Request] --> B(WSGI/ASGI Server)
  B --> C(Middleware Request Phase)
  C --> D(URL Dispatcher)
  D --> E(View Execution)
  E --> F(Middleware Response Phase)
  F --> G[Client Response]

Think of it like an assembly line in a factory. The raw material (request) enters the factory, passes through several inspection stations (middleware), gets routed to the correct machine (view) where it is assembled into a product (response), and then passes through final inspections before being shipped out.

This is a conceptual architecture, implemented internally by Django’s WSGIHandler.

• Synchronous by default, but supports async (ASGI).
• Highly extensible via custom middleware.
• Predictable and sequential.

• Built from: Django Web Framework — the overarching system.
• Related: Django URL Dispatcher — a key step in the lifecycle.
• Related: Django View — the execution step in the lifecycle.
• Related: Django Model — accessed during the view step.

• Middleware order in settings.py is critical. Request phase executes top-down, response phase executes bottom-up.