# URL aus Django-Templates holen: `request.path` vs `path_info` vs `get_full_path` vs `build_absolute_uri` In Django-Templates ist es oft nötig, die aktuelle URL zu kennen. * Navigation – „aktuelles Menü aktivieren“ * Nach dem Login – „zur vorherigen Seite zurückkehren (next)“ * Canonical‑URL / Share‑Link erstellen * Mit Query‑String die „genaue aktuelle Seite“ verlinken Neben `{{ request.path }}` gibt es jedoch mehrere ähnliche Optionen, die leicht verwirren. Heute vergleichen wir die vier wichtigsten sauber. * `request.path` * `request.path_info` * `request.get_full_path()` * `request.build_absolute_uri()` --- ## Woher kommt `{{ request }}`? {#sec-e3874691b2fc} Dass `{{ request }}` in einem Template erscheint, bedeutet in der Regel, dass der **Request‑Context‑Processor** aktiviert ist. * `django.template.context_processors.request` fügt dem Template‑Kontext das `request`‑Objekt hinzu. * Dieser Context‑Processor wird in `TEMPLATES` → `OPTIONS['context_processors']` registriert. Django ist hier meist bereits so vorkonfiguriert, dass `request` im Template-Kontext verfügbar ist – solange man diese Einstellung nicht bewusst entfernt. Das `request`‑Objekt selbst ist eine Instanz von `HttpRequest` (oder einer WSGI/ASGI‑Subklasse), die bei jeder Anfrage erzeugt und an die View weitergereicht wird. Darin befinden sich Attribute wie `path` und `path_info`. ![Django als Zauberer, der Werkzeuge aus dem Hut zieht](/media/editor_temp/6/c112847e-a9ca-4d58-9a3f-076a20bfbef7.png) --- ## Kurzfassung: Merken Sie sich die vier Varianten so {#sec-0f722c9bd67c} * **`path`**: „ohne Domain, nur Pfad“ * **`path_info`**: „der echte Pfad, den die App sieht (ohne Script‑Prefix)“ * **`get_full_path()`**: „`path` + Query‑String“ * **`build_absolute_uri()`**: „Schema + Host + Pfad + Query-String (vollständige URL)“ Schauen wir uns jede Variante im Detail an. --- ## 1) `request.path`: Pfad ohne Domain {#sec-26a629a2d24e} `request.path` liefert den Pfad ohne Schema oder Domain. Beispiel: * `/music/bands/the_beatles/` ### Wann ist es nützlich? {#sec-b307f735685f} * Einfache Vergleiche für Menü‑Aktivierung ```django {% if request.path == "/settings/" %}active{% endif %} ``` * Prefix‑Vergleich, z. B. „zu welcher Kategorie gehört diese Seite?“ ```django {% if request.path|slice:":5" == "/api/" %}...{% endif %} ``` --- ## 2) `request.path_info`: Stabiler Pfad in verschiedenen Deployments {#sec-fd1e8e14948f} Wichtiger Punkt in der Django‑Dokumentation: * In manchen Server‑Konfigurationen wird die URL in **Script‑Prefix (SCRIPT_NAME)** und **path info** aufgeteilt. * `path_info` enthält immer den **path‑info‑Teil**, unabhängig von der Umgebung. Kurz gesagt: In Setups, in denen die App unter einem Präfix wie `/app` läuft (Reverse-Proxy, Sub-Path-Deployment), können `path` und `path_info` unterschiedlich sein. ### Wann ist es nützlich? {#sec-2985f0c9cd7c} * Bei Sub‑Path‑Deployments (z. B. `/app/`) möchte man den Pfad relativ zur App bestimmen. * Wenn sich der Prefix zwischen Test‑ und Produktionsservern unterscheidet. > In einer einfachen Root‑Domain (`/`) sind `path` und `path_info` identisch, aber bei anderen Deployments wird der Unterschied deutlich. --- ## 3) `request.get_full_path()`: Pfad + Query‑String {#sec-1364e4e65388} `get_full_path()` gibt `path` plus Query‑String zurück. Beispiel: * `/music/bands/the_beatles/?print=true` ### Wann ist es nützlich? {#sec-0ac89fe1b7cd} * Link, der die aktuelle Seite exakt abbildet (Share, Refresh, Back) ```django Neuer Link ``` * Nach Login/Autorisierung zur ursprünglichen Seite zurückkehren ```django Login ``` > Django bietet auch `get_full_path_info()`, das auf `path_info` basiert. Es ist nicht Teil dieses Vergleichs, aber nützlich zu kennen. --- ## 4) `request.build_absolute_uri()`: Vollständige URL mit Schema und Host {#sec-0ba80b4c4700} `build_absolute_uri()` erzeugt eine absolute URI basierend auf der aktuellen Anfrage. Beispiel: * `https://example.com/music/bands/the_beatles/?print=true` ### Wann ist es nützlich? {#sec-428d3d6b9613} * E‑Mail‑ oder Messenger‑Links, bei denen die Domain zwingend erforderlich ist * Canonical‑URL, og:url‑Meta‑Tags * Callback‑URL an externe Systeme ### Vorsichtspunkte {#sec-b24dccc132d6} `build_absolute_uri()` nutzt intern `get_host()`, das auf dem Host‑Header der Anfrage basiert. Das bedeutet, es spiegelt nicht unbedingt die tatsächliche URL des Browsers wider. In Umgebungen mit Reverse‑Proxy (Nginx) oder bei bewusst konfigurierten Host‑Logiken kann die erzeugte URL von der realen abweichen. Prüfen Sie daher Ihre Deploy‑Konfiguration, wenn Sie auf die Domain vertrauen. --- ## Fazit und Zusammenfassung {#sec-bd7ea169a316} * **Menü‑Aktivierung in Templates** → `request.path` * **Stabile Pfad‑Vergleich in Sub‑Path‑Deployments** → `request.path_info` * **Query‑String inklusive aktuelle Seite** → `request.get_full_path()` * **Vollständige externe Links (inkl. Domain)** → `request.build_absolute_uri()` --- **Weitere Artikel**: - [Reverse‑Proxy erklärt: Unterschiede zu Forward‑Proxy, Ziele, Einsatzszenarien](/ko/whitedec/2025/12/10/reverse-proxy-forward-proxy-differences/) - [Django von Grund auf neu lernen: Lern‑Roadmap ab HTTP](/ko/whitedec/2025/12/22/django-first-learning-roadmap/)