# Получение 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 Ссылка на обновление ``` * При проверке прав доступа и возврате пользователя на исходную страницу ```django Вход ``` > В 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](/ko/whitedec/2025/12/22/django-first-learning-roadmap/)