Hogyan működik a kérés életciklusa a Django-ban?

Question

IT Interview Practice · Accepted Answer

A Django-ban egy kérést a **WSGI/ASGI handler** kezel, egy **middleware**-verem veszi körül, az **URL resolver** irányítja egy **view**-hoz, majd `HttpResponse`-zá alakul, amely ugyanazon a middleware-en át, fordított sorrendben áramlik vissza kifelé.

## A szakaszok

```
Web server ──▶ WSGI/ASGI handler  (létrehozza a HttpRequest-et)
   ▼
Middleware — kérés fázis           (fentről → lefelé: __call__ a get_response előtt)
   ▼
URL resolver (urls.py)  ── illeszti a path-t → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (function / class-based)  ── a logikád, visszaad egy HttpResponse-t
   ▼
Middleware — response fázis         (lentről → felfelé: a get_response után)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — a WSGI (szinkron) vagy ASGI (aszinkron) handler egy `HttpRequest`-et épít az environ/scope alapján.
2. **Middleware, kérés fázis** — minden middleware `get_response()` *előtti* kódja fentről lefelé fut (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Bármelyik rövidre zárhat, és korán visszaadhat egy response-t.
3. **URL feloldás** — a `ROOT_URLCONF` mintáit illeszti a path-hoz, hogy kiválasszon egy view-t, és elkapja a kwargokat.
4. **`process_view`** — egy middleware hook, amely közvetlenül a view meghívása előtt fut.
5. **View** — a függvény- vagy osztályalapú view-d lefut, tipikusan modelleket lekérdez és egy templatet renderel, majd visszaad egy `HttpResponse`-t. A kivételek kiváltják a `process_exception`-t.
6. **Middleware, response fázis** — a `get_response()` *utáni* kód lentről felfelé fut, engedve, hogy a middleware módosítsa a kimenő response-t (headerök, tömörítés).
7. Az `HttpResponse` visszaáramlik a szerverhez és a klienshez.

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

def __call__(self, request):          # 2. kérés fázis (előtte)
        request.started = time.monotonic()
        response = self.get_response(request)  # meghívja a következő réteget / view-t
        response["X-Time"] = "..."         # 6. response fázis (utána)
        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)})
```

## Miért fontos

A Django kérés/response ciklusa middleware-központú, így a legtöbb keresztmetsző viselkedés — auth, session, CSRF, security headerök, cache-elés — rendezett middleware-ként van megvalósítva. Annak megértése, hogy a kérés-fázis kódja fentről lefelé, a response-fázis kódja pedig lentről felfelé fut (és hogy a `MIDDLEWARE` sorrendje számít), elengedhetetlen a saját middleware-ed helyes elhelyezéséhez, annak hibakereséséhez, miért történik egy `403`/átirányítás a view-d előtt, és annak megismeréséhez, hol lehet logikát bekötni anélkül, hogy minden egyes view-hoz hozzá kellene nyúlni.

A szakaszok

Miért fontos

Kapcsolódó kérdések