Location

Применение

Серверы включают Location, когда направляют клиентов на другой URL. Этот заголовок встречается в двух контекстах: в ответах-перенаправлениях и при создании ресурса.

При перенаправлениях значение Location сообщает клиенту, куда отправить следующий запрос. Поведение зависит от кода состояния:

При создании ресурса ответ 201 Created включает Location, указывающий на вновь созданный ресурс. Это даёт клиенту прямую ссылку без необходимости выполнять дополнительный поиск.

Значение Location принимает как абсолютные, так и относительные URL. Относительные URL разрешаются относительно URI запроса.

Примечание

Заголовок Location и заголовок Content-Location служат разным целям. Location указывает на цель перенаправления или на вновь созданный ресурс. Content-Location определяет прямой URL возвращённого представления.

Примечание

Поисковые системы следуют за перенаправлениями и передают ссылочный вес (ранжирующую ценность) целевому URL при постоянных перенаправлениях (301, 308). Временные перенаправления (302, 307) передают ссылочный вес не всегда. Использование правильного кода состояния при миграции URL сохраняет позиции в поиске.

URL

Значение — одна URI-ссылка, указывающая на целевое местоположение.

Location: <url>

URL — это либо абсолютный URI со схемой и хостом, либо относительная ссылка, разрешаемая относительно URI запроса.

Пример

Постоянное перенаправление со старого домена на новый сообщает клиентам, что нужно обновить закладки и ссылки. При 301 клиентам разрешается сменить метод запроса с POST на GET.

HTTP/1.1 301 Moved Permanently
Location: https://new.example.re/products

Постоянное перенаправление 308 сохраняет исходный метод запроса, благодаря чему перенаправление безопасно для POST и других запросов, отличных от GET.

HTTP/1.1 308 Permanent Redirect
Location: https://new.example.re/products

После создания ресурса через запрос POST сервер возвращает 201 и Location нового ресурса.

HTTP/1.1 201 Created
Location: /api/orders/7891
Content-Type: application/json

Ответ 303 после отправки формы перенаправляет клиента на страницу результатов с использованием GET.

HTTP/1.1 303 See Other
Location: /search/results?q=http+headers

Диагностика

Сбои перенаправления часто проявляются как бесконечные циклы, неработающие URL или отсутствующие заголовки в ответе.

Цикл перенаправлений. Заголовок Location указывает обратно на текущий URL или на другой URL, который перенаправляет назад, образуя бесконечный цикл. Браузеры останавливаются после заданного числа переходов и показывают ошибку ERR_TOO_MANY_REDIRECTS. Проследите цепочку с помощью curl -L -v, чтобы выявить цикл. Распространённые причины: серверное правило перенаправляет HTTP на HTTPS, тогда как балансировщик нагрузки перенаправляет HTTPS обратно на HTTP, либо правила nginx return 301 совпадают с целевым URL. В nginx применяйте ограждение if ($scheme = http) узко и тестируйте оба протокола.

Относительный URL разрешается неправильно. Значение Location принимает относительные ссылки, но некоторые старые клиенты и промежуточные узлы ожидают абсолютный URL. Путь вида /new-page разрешается относительно URI запроса. Пропуск ведущей косой черты создаёт относительный путь, который разрешается относительно текущего каталога, что приводит к неожиданным результатам. Используйте абсолютные URL со схемой и хостом, чтобы избежать неоднозначности.

Отсутствующий заголовок Location в ответе 3xx. Код состояния перенаправления без заголовка Location оставляет клиента без пункта назначения. Браузеры показывают пустую страницу или ошибку. Проверьте ответ сервера командой curl -I https://example.re/old-path и убедитесь, что заголовок присутствует. В Apache директивы Redirect и RedirectMatch всегда включают этот заголовок. Собственный код приложения должен устанавливать заголовок явно.

Несовпадение протокола в цели перенаправления. HTTP-адрес в заголовке Location на HTTPS-сайте вызывает предупреждения о смешанном содержимом или блокирует перенаправление в строгих окружениях. Убедитесь, что целевой URL соответствует исходному протоколу или повышает его до HTTPS. В nginx используйте return 301 https://$host$request_uri;, чтобы сохранить защищённую схему.

Фрагмент не сохраняется при перенаправлениях. Идентификатор фрагмента (#section) из исходного URL не передаётся в заголовке Location. Браузеры заново прикрепляют исходный фрагмент к цели перенаправления только тогда, когда целевой URL не содержит собственного фрагмента. Если значение Location включает другой фрагмент, исходный теряется. Серверный код не имеет доступа к фрагментам, поскольку браузеры не отправляют их в запросах.

Отладка цепочек перенаправлений. Выполните curl -L -v https://example.re/start, чтобы пройти по всем перенаправлениям и увидеть каждый переход с кодами состояния и заголовками. Вкладка Network в DevTools также показывает полную цепочку. Отфильтруйте по типу «документ», чтобы отделить ответы-перенаправления от запросов подресурсов.