# 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? {#sec-e3874691b2fc}
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`.

---
## Eén regel conclusie: onthoud de vier methoden {#sec-0f722c9bd67c}
* **`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 {#sec-26a629a2d24e}
`request.path` geeft alleen het verzoekpad zonder domein of schema. Voorbeeld:
* `/music/bands/the_beatles/`
### Wanneer is dit handig? {#sec-b307f735685f}
* 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 {#sec-fd1e8e14948f}
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? {#sec-2985f0c9cd7c}
* 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 {#sec-1364e4e65388}
`get_full_path()` retourneert het pad inclusief de querystring. Voorbeeld:
* `/music/bands/the_beatles/?print=true`
### Wanneer is dit handig? {#sec-0ac89fe1b7cd}
* Een link om de huidige pagina te delen, te verversen of terug te gaan
```django
Vernieuw link
```
* Bij login of autorisatie om de gebruiker terug te sturen naar de oorspronkelijke pagina
```django
Login
```
> 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 {#sec-0ba80b4c4700}
`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? {#sec-428d3d6b9613}
* 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 {#sec-b24dccc132d6}
`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 {#sec-bd7ea169a316}
* **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**:
- [Reverse proxy: verschillen met forward proxy, doelen en gebruiksscenario’s](/ko/whitedec/2025/12/10/reverse-proxy-forward-proxy-differences/)
- [Django opnieuw leren: een leer‑roadmap vanaf HTTP](/ko/whitedec/2025/12/22/django-first-learning-roadmap/)