# Получение URL в шаблонах Django: `request.path` vs `path_info` vs `get_full_path` vs `build_absolute_uri`

В шаблонах Django часто требуется знать текущий URL.

* Навигация «активировать текущий пункт меню»
* После входа в систему «вернуться к ранее просматриваемой странице (next)»
* Создание канонического URL / ссылки для совместного использования
* Создание ссылки «на текущую страницу с сохранением строк запроса»

Однако помимо `{{ request.path }}` существует несколько похожих вариантов, что может сбивать с толку. Сегодня мы разберём только четыре наиболее часто используемых.

* `request.path`
* `request.path_info`
* `request.get_full_path()`
* `request.build_absolute_uri()`

---

## Откуда берётся `{{ request }}` {#sec-e3874691b2fc}

Появление `{{ request }}` в шаблоне обычно означает, что включён **контекстный процессор запросов**.

* `django.template.context_processors.request` **добавляет объект `request` в контекст шаблона**.
* Этот процессор активируется, когда он зарегистрирован в `TEMPLATES` → `OPTIONS['context_processors']`.

То есть Django по умолчанию добавляет `request` в глобальный контекст, если пользователь не удалит эту настройку. Поэтому большинство разработчиков используют `request` без лишних усилий.

Сам объект `request` создаётся Django при получении HTTP‑запроса (на самом деле это подкласс `HttpRequest` для WSGI/ASGI) и передаётся в представление. В нём находятся атрибуты `path`, `path_info` и другие.

![Django как волшебник, вытаскивающий инструменты из шляпы](/media/editor_temp/6/c112847e-a9ca-4d58-9a3f-076a20bfbef7.png)

---

## Быстрый вывод: как запомнить 4 варианта {#sec-0f722c9bd67c}

* **`path`**: «только путь без домена»
* **`path_info`**: «реальный путь, видимый приложением (без префикса скрипта)»
* **`get_full_path()`**: «`path` + строка запроса»
* **`build_absolute_uri()`**:«полный URL: схема + хост + путь + строка запроса»

Теперь разберём каждый из них подробнее.

---

## 1) `request.path`: путь без домена {#sec-26a629a2d24e}

`request.path` возвращает **только путь запроса**, без схемы и хоста. Пример:

* `/music/bands/the_beatles/`

### Когда это удобно {#sec-b307f735685f}

* Простое сравнение для активации меню

  ```django
  {% if request.path == "/settings/" %}active{% endif %}
  ```
* Определение категории по префиксу

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

---

## 2) `request.path_info`: путь, устойчивый к разным средам развертывания {#sec-fd1e8e14948f}

Ключевой момент из документации Django:

* В некоторых конфигурациях URL‑путь разделяется на **префикс скрипта (SCRIPT_NAME)** и **path info**.
* `path_info` всегда содержит именно часть **path info**, поэтому менее зависит от окружения.

То есть, если приложение монтируется под `/app` (через обратный прокси, субпуть и т.д.), `path` и `path_info` могут отличаться.

### Когда это удобно {#sec-2985f0c9cd7c}

* При развертывании под субпутём (например, `/app/`) и необходимости сравнивать «путь приложения».
* При тестировании и продакшене, где префикс может отличаться.

> Если приложение работает только под корневым доменом (`/`), `path` и `path_info` совпадают, и разница не заметна. При смене окружения разница становится важной.

---

## 3) `request.get_full_path()`: путь + строка запроса {#sec-1364e4e65388}

`get_full_path()` возвращает **`path` с добавленной строкой запроса**. Пример:

* `/music/bands/the_beatles/?print=true`

### Когда это удобно {#sec-0ac89fe1b7cd}

* Создание ссылки «на текущую страницу с сохранением параметров»

  ```django
  <a href="{{ request.get_full_path }}">Ссылка на обновление</a>
  ```
* При проверке прав доступа и возврате пользователя на исходную страницу

  ```django
  <a href="/login/?next={{ request.get_full_path|urlencode }}">Вход</a>
  ```

> В Django есть также `get_full_path_info()`, который основан на `path_info`. Это не рассматриваем в данном сравнении, но полезно знать.

---

## 4) `request.build_absolute_uri()`: полный URL с схемой и хостом {#sec-0ba80b4c4700}

`build_absolute_uri()` формирует **абсолютный URL** на основе текущего запроса.

Пример:

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

### Когда это удобно {#sec-428d3d6b9613}

* При отправке ссылок в письмах или мессенджерах, где нужен полный URL.
* Для мета‑тегов `canonical`, `og:url` и т.п.
* При передаче callback‑URL внешним системам.

### Что нужно учитывать {#sec-b24dccc132d6}

`build_absolute_uri()` использует информацию о хосте из запроса (`get_host()`). Это **не обязательно совпадает с реальным URL в браузере**. Если Nginx работает как обратный прокси или в Django реализована логика, меняющая хост, результат может отличаться от ожидаемого. Поэтому при работе с доменами важно проверять настройки развертывания.

---

## Итоги и резюме {#sec-bd7ea169a316}

* **Активация меню в шаблоне** → `request.path`
* **Стабильное сравнение в субпутевых/прокси‑окружениях** → `request.path_info`
* **Включение строки запроса** → `request.get_full_path()`
* **Полный внешний URL** → `request.build_absolute_uri()`

---

**Смотрите также**:

- [Что такое обратный прокси? Различия с прямым прокси, цели и сценарии использования](/ko/whitedec/2025/12/10/reverse-proxy-forward-proxy-differences/)
- [Если вы хотите заново изучить Django: дорожная карта от HTTP](/whitedec/2025/12/22/django-first-learning-roadmap/)