URL ophalen in Django‑templates: request.path vs path_info vs get_full_path vs build_absolute_uri

In Django‑templates komt het vaak voor dat je de huidige URL nodig hebt.

  • Navigatie‑menu’s: “huidig item activeren”
  • Na inloggen: “terug naar de pagina die je zojuist zag” (next)
  • Canonical URL / deel‑link genereren
  • De huidige pagina inclusief querystring delen

Maar naast {{ request.path }} zijn er nog andere, vergelijkbare opties, wat verwarring kan veroorzaken. In dit artikel vergelijken we de vier meest gebruikte:

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

Waar komt {{ request }} vandaan?

Het verschijnen van {{ request }} in een template betekent meestal dat de request context processor is ingeschakeld.

  • django.template.context_processors.request voegt het request‑object toe aan de template‑context.
  • Deze context processor wordt geactiveerd wanneer hij is geregistreerd in TEMPLATES → OPTIONS['context_processors'].

Django plaatst standaard het request‑object in de globale context, tenzij je dit expliciet uitschakelt. Het request‑object zelf is een HttpRequest (in feite een WSGI/ASGI‑subclass) dat Django aan de view doorgeeft. Het bevat attributen zoals path en path_info.

Django‑magier die een tool uit een hoed haalt

Eén regel conclusie: onthoud de vier methoden

  • path: “alleen het pad, zonder domein”
  • path_info: “het echte pad dat de app ziet (zonder script‑prefix)”
  • get_full_path(): “path + querystring”
  • build_absolute_uri(): “schema + host + pad + querystring (volledige URL)”

Laten we nu elk van hen in detail bekijken.

1) request.path: het pad zonder domein

request.path geeft alleen het verzoekpad zonder domein of schema. Voorbeeld:

  • /music/bands/the_beatles/

Wanneer is dit handig?

  • Eenvoudige vergelijkingen voor menu‑activatie

django {% if request.path == "/settings/" %}active{% endif %} * Prefix‑vergelijking om te bepalen in welke categorie de pagina valt

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

2) request.path_info: het echte pad, minder afhankelijk van de omgeving

De kernpunten uit de Django‑documentatie zijn:

  • In sommige serverconfiguraties wordt het URL‑pad opgesplitst in SCRIPT_NAME (script‑prefix) en PATH_INFO.
  • path_info bevat altijd het PATH_INFO‑gedeelte, dus is minder afhankelijk van de omgeving.

Kort gezegd: bij een app die onder een prefix zoals /app draait (bijv. via een reverse proxy of sub‑path deployment), kunnen path en path_info verschillen.

Wanneer is dit handig?

  • Bij sub‑path deployments (bijv. /app/) wil je het pad op app‑niveau bepalen.
  • Bij test‑ en productie‑servers met verschillende prefixes.

In een typische root‑domain (/) zijn path en path_info gelijk, maar bij een andere omgeving kunnen ze verschillen.

3) request.get_full_path(): path + querystring

get_full_path() retourneert het pad inclusief de querystring. Voorbeeld:

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

Wanneer is dit handig?

  • Een link om de huidige pagina te delen, te verversen of terug te gaan

django <a href="{{ request.get_full_path }}">Vernieuw link</a> * Bij login of autorisatie om de gebruiker terug te sturen naar de oorspronkelijke pagina

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

Django heeft ook get_full_path_info(), die gebaseerd is op path_info. Dit is niet het onderwerp van dit artikel, maar het is goed om te weten.

4) request.build_absolute_uri(): volledige URL inclusief schema en host

build_absolute_uri() genereert een absolute URI op basis van het huidige verzoek.

Voorbeeld:

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

Wanneer is dit handig?

  • E‑mail of messenger‑links waar het domein noodzakelijk is
  • Canonical URL, og:url en andere meta‑tags
  • Callback‑URL’s naar externe systemen

Let op

build_absolute_uri() vertrouwt op de Host‑informatie van het verzoek (get_host()). Het is dus niet per se de exacte URL die de gebruiker heeft opgevraagd.In omgevingen met reverse proxies of aangepaste host‑logica kan de gegenereerde URL afwijken van de echte browser‑URL. Controleer daarom je deployment‑configuratie als je domein‑specifieke logica hebt.

Conclusie en samenvatting

  • Menu‑activatie in templates → request.path
  • Stabiele vergelijking in sub‑path deployments → request.path_info
  • Querystring inbegrepen voor “dezelfde pagina” → request.get_full_path()
  • Volledige link voor externe gebruik → request.build_absolute_uri()

Gerelateerde artikelen: