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 }}?

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

Kurzfassung: Merken Sie sich die vier Varianten so

  • 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

request.path liefert den Pfad ohne Schema oder Domain. Beispiel:

  • /music/bands/the_beatles/

Wann ist es nützlich?

  • 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

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?

  • 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

get_full_path() gibt path plus Query‑String zurück. Beispiel:

  • /music/bands/the_beatles/?print=true

Wann ist es nützlich?

  • Link, der die aktuelle Seite exakt abbildet (Share, Refresh, Back)

django <a href="{{ request.get_full_path }}">Neuer Link</a> * Nach Login/Autorisierung zur ursprünglichen Seite zurückkehren

django <a href="/login/?next={{ request.get_full_path|urlencode }}">Login</a>

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

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?

  • E‑Mail‑ oder Messenger‑Links, bei denen die Domain zwingend erforderlich ist
  • Canonical‑URL, og:url‑Meta‑Tags
  • Callback‑URL an externe Systeme

Vorsichtspunkte

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

  • 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: