('

URL aus Django-Templates holen: request.path vs path_info vs get_full_path vs build_absolute_uri

\n

In Django-Templates ist es häufig nötig, die aktuelle URL zu kennen.

\n
    \n
  • Navigation – „aktuelles Menü aktivieren“
    • \n
  • Nach dem Login – „zur vorherigen Seite zurückkehren (next)“
    • \n
  • Canonical‑URL / Share‑Link erstellen
    • \n
  • Mit Query‑String die „genaue aktuelle Seite“ verlinken
    • \n
\n

Doch neben {{ request.path }} gibt es noch mehrere ähnliche Optionen, die leicht verwirren. Heute vergleichen wir die vier wichtigsten sauber.

\n
    \n
  • request.path
    • \n
  • request.path_info
    • \n
  • request.get_full_path()
    • \n
  • request.build_absolute_uri()
    • \n
\n
\n

Woher kommt {{ request }}?

\n

Dass {{ request }} in einem Template erscheint, bedeutet in der Regel, dass der Request‑Context‑Processor aktiviert ist.

\n
    \n
  • django.template.context_processors.request fügt dem Template‑Kontext das request‑Objekt hinzu.
    • \n
  • Dieser Context‑Processor wird in TEMPLATES → OPTIONS[\'context_processors\'] registriert.
    • \n
\n

Django legt standardmäßig das request‑Objekt als globalen Kontext ein, sodass Entwickler es nicht explizit entfernen müssen. 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.

\n

Django als Zauberer, der Werkzeuge aus dem Hut zieht

\n
\n

Kurzfassung: Merken Sie sich die vier Varianten so

\n
    \n
  • path: „ohne Domain, nur Pfad“
    • \n
  • path_info: „der echte Pfad, den die App sieht (ohne Script‑Prefix)“
    • \n
  • get_full_path(): „path + Query‑String“
    • \n
  • build_absolute_uri(): „Schema + Host + Pfad (vollständige URL)“
    • \n
\n

Jetzt betrachten wir jede Variante im Detail.

\n
\n

1) request.path: Pfad ohne Domain

\n

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

\n
    \n
  • /music/bands/the_beatles/
    • \n
\n

Wann ist es nützlich?

\n
    \n
  • Einfache Vergleiche für Menü‑Aktivierung
    • \n
\n

django\n {% if request.path == "/settings/" %}active{% endif %}\n* Prefix‑Vergleich, z.\u202fB. „zu welcher Kategorie gehört diese Seite?“

\n

django\n {% if request.path|slice:":5" == "/api/" %}...{% endif %}

\n
\n

2) request.path_info: Stabiler Pfad in verschiedenen Deployments

\n

Wichtiger Punkt in der Django‑Dokumentation:

\n
    \n
  • In manchen Server‑Konfigurationen wird die URL in Script‑Prefix (SCRIPT_NAME) und path info aufgeteilt.
    • \n
  • path_info enthält immer den path‑info‑Teil, unabhängig von der Umgebung.
    • \n
\n

Kurz gesagt: In Setups, wo die App unter einem Prefix wie /app läuft (Reverse‑Proxy, Sub‑Path‑Deployment), können path und path_info unterschiedlich sein.

\n

Wann ist es nützlich?

\n
    \n
  • Bei Sub‑Path‑Deployments (z.\u202fB. /app/) möchte man den Pfad relativ zur App bestimmen.
    • \n
  • Wenn sich der Prefix zwischen Test‑ und Produktionsservern unterscheidet.
    • \n
\n
\n

In einer einfachen Root‑Domain (/) sind path und path_info identisch, aber bei anderen Deployments wird der Unterschied deutlich.

\n
\n
\n

3) request.get_full_path(): Pfad + Query‑String

\n

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

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

Wann ist es nützlich?

\n
    \n
  • Link, der die aktuelle Seite exakt wiederholt (Share, Refresh, Back)
    • \n
\n

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

\n

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

\n
\n

Django bietet auch get_full_path_info(), das auf path_info basiert. Es ist nicht Teil dieses Vergleichs, aber nützlich zu kennen.

\n
\n
\n

4) request.build_absolute_uri(): Vollständige URL mit Schema und Host

\n

build_absolute_uri() erzeugt eine absolute URI basierend auf der aktuellen Anfrage.

\n

Beispiel:

\n
    \n
  • https://example.com/music/bands/the_beatles/?print=true
    • \n
\n

Wann ist es nützlich?

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

Vorsichtspunkte

\n

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.

\n
\n

Fazit und Zusammenfassung

\n
    \n
  • Menü‑Aktivierung in Templates → request.path
    • \n
  • Stabile Pfad‑Vergleich in Sub‑Path‑Deployments → request.path_info
    • \n
  • Query‑String inklusive aktuelle Seite → request.get_full_path()
    • \n
  • Vollständige externe Links (inkl. Domain) → request.build_absolute_uri()
    • \n
\n
\n

Weitere Artikel:

\n', '/media/editor_temp/6/c112847e-a9ca-4d58-9a3f-076a20bfbef7.png')