Hvordan fungerer en requests livscyklus i Django?

Question

IT Interview Practice · Accepted Answer

I Django håndteres en request af **WSGI/ASGI-handleren**, pakkes ind af en stak af **middleware**, routes af **URL-resolveren** til et **view** og omdannes til en `HttpResponse`, der flyder tilbage ud gennem det samme middleware i omvendt rækkefølge.

## Faserne

```
Web server ──▶ WSGI/ASGI handler  (opretter HttpRequest)
   ▼
Middleware — request-fase        (top → bund: __call__ før get_response)
   ▼
URL resolver (urls.py)  ── match path → view + kwargs
   ▼
Middleware — process_view-hook
   ▼
View (function / class-based)  ── din logik, returnerer HttpResponse
   ▼
Middleware — response-fase        (bund → top: efter get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI- (sync) eller ASGI- (async) handleren bygger en `HttpRequest` ud fra environ/scope.
2. **Middleware, request-fase** — hvert middlewares kode *før* `get_response()` kører top-til-bund (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Enhver af dem kan kortslutte og returnere et svar tidligt.
3. **URL-opløsning** — `ROOT_URLCONF`-mønstre matches mod stien for at vælge et view og fange kwargs.
4. **`process_view`** — et middleware-hook, der kører lige før viewet kaldes.
5. **View** — dit funktions- eller klassebaserede view kører, forespørger typisk modeller og renderer en template, og returnerer en `HttpResponse`. Undtagelser udløser `process_exception`.
6. **Middleware, response-fase** — kode *efter* `get_response()` kører bund-til-top og lader middleware ændre det udgående svar (headers, komprimering).
7. `HttpResponse` streames tilbage til serveren og klienten.

```python
# middleware.py
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

def __call__(self, request):          # 2. request-fase (før)
        request.started = time.monotonic()
        response = self.get_response(request)  # kalder næste lag / view
        response["X-Time"] = "..."         # 6. response-fase (efter)
        return response

# urls.py  → 3. routing
urlpatterns = [path("items/<int:pk>/", views.item_detail)]

# views.py → 5. view
def item_detail(request, pk):
    return render(request, "item.html", {"item": Item.objects.get(pk=pk)})
```

## Hvorfor det betyder noget

Djangos request/response-cyklus er middleware-centreret, så det meste tværgående adfærd — auth, sessioner, CSRF, security-headers, caching — implementeres som ordnet middleware. At forstå, at request-fasens kode kører top-ned og response-fasens kode kører bund-op (og at rækkefølgen i `MIDDLEWARE` betyder noget), er essentielt for at placere dit eget middleware korrekt, fejlfinde hvorfor en `403`/redirect sker før dit view, og vide hvor du kan hægte logik på uden at røre hvert eneste view.

Faserne

Hvorfor det betyder noget

Relaterede spørgsmål