Перенаправления in HTTP. Редиректы с использованием HTTPS

В связи с массовым переходом сайтов на HTTPS перед разработчиками и администраторами сайтов встал ряд новых проблем. Одной из них является редирект с HTTP на HTTPS и необходимость правильно обрабатывать переадресацию на канонический адрес сайта, чтобы избежать дублирования контента.

HTTPS и редиректы

Рассмотрим пример. Допустим, что у нас есть сайт dnsimple.com . Его канонический URL-адрес — https://dnsimple.com . Тем не менее, существует четыре различных способа, с помощью которых можно подключиться к сайту, и нужно обеспечить, чтобы при любом из них пользователь перенаправлялся на https://dnsimple.com :

Исходный способ	Тип
http://dnsimple.com	HTTP + no-www
https://dnsimple.com	HTTPS + no-www
http://www.dnsimple.com	HTTP + www
https://www.dnsimple.com	HTTPS + www

Настройка htaccess редиректов HTTP на HTTPS часто является причиной путаницы. Не всегда понятно, как правильно обрабатывать через HTTPS редиректы с WWW на не-WWW (или наоборот ), и почему для этого нужен сертификат SSL / TLS . Чтобы правильно настроить эти перенаправления, необходимо понять основные принципы обработки запросов HTTPS .

Далее мы рассмотрим, в каком порядке устанавливается соединение по протоколу HTTPS , как происходит обработка HTTP-запросов и настройка редиректов с поддержкой HTTPS .

Поток запроса HTTPS

На приведенном выше изображении показана схема прохождения запросов / ответов HTTPS . Для простоты мы разбили все действия на три фазы:

На первом этапе клиент и сервер договариваются о деталях шифрования, таких как протокол шифрования и набор шифров. Также происходит обмен информацией, необходимой для переключения на защищенное соединение: открытые ключи, сведения о сертификате и т.д. Эта фаза называется «SSL / TLS рукопожатие »;
На втором этапе клиент готовит HTTP-запрос , шифрует его и отправляет на сервер для обработки. Сервер принимает зашифрованный HTTP-запрос , расшифровывает его, обрабатывает и выдает HTTP response (ответ );
На третьем этапе, сервер шифрует ответ и отправляет его клиенту для обработки. Клиент получает зашифрованный HTTP response , дешифрует и обрабатывает его (например, браузер начинает загружать и отображать элементы ).

Эта схема потока редиректа с HTTP на HTTPS применима к любому запросу, независимо от содержимого ответа HTTP .

Выше я написал запрос HTTP и ответ HTTP для определенных целей (обратите внимание, что я использовал HTTP , а не HTTPS ). С точки зрения содержимого и структуры важно понимать, что HTTPS-запрос — это HTTP-запрос , но передаваемый через защищенное соединение (TLS / SSL ).

HTTPS-согласования и редиректы

Одна из самых распространенных ошибок при настройке HTTPS-редиректов — это предположение, что вам не нужен сертификат SSL при переадресации клиента с одного домена на другой.

Если посмотреть на поток запросов, то видно, что обмен сертификатами SSL и согласование шифрования выполняются на первом этапе. Обратите внимание, что на этом этапе сервер ничего не знает, какая страница нужна клиенту: клиент и сервер решают, как взаимодействовать друг с другом.

После завершения первого этапа, когда клиент и сервер нашли общий язык (протокол шифрования ), они могут начать взаимодействовать друг с другом, используя зашифрованное соединение. В этот момент клиент отправляет HTTP-запрос на сервер, а сервер отправляет HTTP-ответ , содержащий редирект.

Не забывайте, что редирект — это HTTP-ответ с кодом 301 (иногда 302 или 307 ):

HTTP/1.1 301 Moved Permanently Server: nginx Date: Mon, 01 Aug 2016 14:41:25 GMT Location: https://dnsimple.com/

Перед тем, как сделать редирект с HTTPS на HTTP , помните, что, если нужно создать редирект для всего домена, то необходим валидный сертификат SSL для перенаправляемого домена. Для согласования шифрования требуется сертификат SSL , и происходит оно до того, как запрос был обработан, а ответ о редиректе возвращен клиенту.

Если бы все происходило иначе, то редирект бы обрабатывался перед проверкой сертификата SSL . Тогда клиент и сервер были бы вынуждены общаться с помощью обычного HTTP-соединения , которое не шифруется.

Если нужно перенаправить клиента с любой страницы домена https://www.example.com на другую, необходим установленный на сервере валидный сертификат SSL , который распространяется на весь домен www.example.com .

Например, чтобы перенаправить клиента с https://www.example.com на https://example.com , необходимо иметь сертификат, который распространяется на оба или два отдельных сертификата (для каждого хоста соответственно ).

Стратегии HTTPS-редиректов

Мы рассмотрели, как обрабатывается редирект с HTTP на HTTPS через htaccess после SSL / TLS согласования. А также выяснили, что для перенаправления клиентов с сайта или страницы на HTTPS нужен валидный сертификат SSL , который охватывает оба домена. Далее я расскажу об общих стратегиях настройки HTTPS-редиректов .

Существует два типа настройки редиректов с HTTPS :

Редирект на уровне сервера;
Редирект на уровне приложений.

Термин сервер обозначает любой сервер, который находится перед веб-приложением и обрабатывает входящий HTTP-запрос . Например, front-end сервер, сервер балансировки нагрузки или единичного приложения.

Термин приложение обозначает веб-приложение, которое может быть либо столь же простым, как PHP-скрипт , либо более сложным, таким как серверное Unicorn-приложение интерпретации Ruby on Rails .

Выполнение HTTPS-редиректов на уровне сервера

Выполнение HTTPS-редиректов на уровне сервера является более предпочтительным. В этом случае сервер, на котором установлен сертификат SSL , принимает зашифрованный HTTP-запрос и возвращает зашифрованный HTTP-ответ о редиректе в соответствии с параметрами конфигурации без соединения с сервером приложения или выполнения кода приложения.

Такой подход является более быстрым, так как сервер может обрабатывать редирект без взаимодействия с приложением. В то же время конфигурация серверов менее гибкая по сравнению с тем, что можно сделать с помощью полноценного языка программирования.
htaccess редирект HTTP на HTTPS на уровне сервера используется для массового перенаправления. Например, редиректа с WWW на не-WWW версию домена с HTTPS (или наоборот ).

Следующий фрагмент кода является примером конфигурации Nginx , в котором задается редирект с http://example.com , http://www.example.com и https://www.example.com на https://example.com :

server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl; server_name example.com www.example.com; # ssl configuration ssl on; ssl_certificate /path/to/certificate.crt; ssl_certificate_key /path/to/private.key; if ($http_host = www.example.com) { return 301 https://example.com$request_uri; } }

Реализация редиректа на уровне сервера более предпочтительна, но она не всегда осуществима, поскольку вы можете не иметь доступа к конфигурации сервера. Это касается виртуального хостинга или таких платформ, как Heroku , Azure или Google Platform .

Выполнение HTTPS-редиректа на уровне приложений

Когда у вас нет доступа к конфигурации сервера, или логика редиректа является более сложной, необходимо обрабатывать редирект с HTTP на HTTPS на уровне приложений.

Такой подход немного медленнее, потому что сервер должен принять запрос, обработать код приложения (или взаимодействовать с сервером приложений ) и вернуть ответ.

То, как выполняется редирект на уровне приложений, зависит от используемого языка программирования и стека. Вот несколько примеров.

Пакет Goland и net/http

Можно использовать http.Redirect .

Ruby on Rails

Можно настроить редирект на уровне маршрутизатора, использовать промежуточное программное обеспечение Rack или метод redirect_to внутри контроллера:

constraints(host: /www.example.com/) do get "*", to: redirect("https://example.com") end

PHP

Используйте функцию header , чтобы отправить HTTP-заголовок перенаправления:

В некоторых случаях это единственно возможный подход. Например, если нужно перенаправить клиентов с WWW на не-WWW версию домена, с HTTPS на Heroku или Azure (или наоборот ), то придется указать оба домена в одном приложении, установить сертификат и через условия обрабатывать редирект на уровне приложений.

Альтернативные способы выполнения HTTPS-редиректа

Существует несколько альтернативных способов редиректа с HTTP на HTTPS .

В некоторых ситуациях отсутствует доступ к конфигурации сервера, а платформа, на которой размещен сайт, не позволяет использовать язык программирования. В качестве типичного примера можно привести Amazon S3 для размещения статических сайтов. В этом случае нужно выяснить, предоставляет ли платформа параметры HTTPS-редиректов , которые можно настроить.

Другой вариант заключается в использовании автономного, независимого приложения для редиректов. Например, если нужно перенаправить клиентов с https://alpha.com на https://beta.com . Тогда для домена alpha.com в качестве DNS можно указать другой сервис или сервер, на котором размещен beta.com . А также настроить редирект на уровне сервера или установить приложение, которое будет выступать в качестве редиректора. При этом также необходим валидный сертификат для alpha.com , который будет установлен там, где необходимо осуществить редирект.

URL перенаправление (redirecting), также известное как URL пересылка (forwarding), это метод представления страницы, формы или целого веб-приложения, более чем одним URL адресом. HTTP предоставляет специальный вид ответов, HTTP redirect , для выполнения этой операции, используемой для многих целей: временного перенаправления, пока выполняется обслуживание сайта, постоянное перенаправление, для сохранения работоспособности внешних ссылок, после смены архитектуры сайта, страниц прогресса, пока загружается файл, и так далее.

Принцип работы

В HTTP, перенаправление вызывается при отправке сервером специального ответа на запрос: redirects. HTTP перенаправление, это ответы с кодом статуса 3xx . Когда браузер получает ответ перенаправления, он использует новый предоставленный URL-адрес и немедленно загружает его: в большинстве случаев переадресация невидима для пользователя, за исключением небольшого влияния производительность.

Есть несколько типов перенаправлений и делятся на три категории: постоянные, временные и специальные перенаправления.

Постоянные перенаправления

Эти перенаправления призваны длиться вечно. Они подразумевают, что оригинальный URL-адрес больше не должен использоваться, а вместо него должен быть использован новый. Поисковые роботы запускают обновление связанного URL-адреса для ресурса в своих индексах.

Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 308 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.

Временные перенаправления

Иногда, доступ к запрашиваемому ресурсу не может быть предоставлен из определенного места, но может быть предоставлен из другого. В этом случае, могут быть использованы временные перенаправления. Поисковые роботы не запоминают новую, временную ссылку. Временные перенаправления также используются, когда создаются, обновляются, или удаляются ресурсы, которые представляют временные страницы.

Код	Текст	Обработка метода	Случаи использования
302	Found	GET методы неизменны. Другие методы могут быть превращены в GET .	Веб-страница недоступна по непредвиденым причинам. В этом случае поисковые роботы не будут обновлять свои ссылки.
303	See Other	GET методы неизменны. Другие превращены в GET (тело запроса теряется).	Используется для перенаправления после PUT или POST для предотвращения обновления страницы, что может спровоцировать повторный вызов операции.
307	Temporary Redirect	Метод и тело запроса неизменны.	Веб-страница недоступна по непредвиденным причинам. В этом случае поисковые роботы не будут обновлять свои ссылки. Лучше чем код 302 когда не-GET ссылки/операции доступны на сайте.

Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 307 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.

Специальные перенаправления

В добавок к обычным перенаправлениям, есть 2 специальные. Перенаправление с кодом (Not Modified) перенаправляет страницу к локальной закешированной копии (которая была устаревшей), и перенаправление с кодом (Multiple Choice) это ручное перенаправление: тело, представленное браузером, как веб-страница, перечисляет возможные перенаправления и пользователь выбирает одно из них.

Альтернативные способы указания перенаправлений

HTTP перенаправления это не единственный способ переадресации. Есть еще два метода: HTML перенаправления используют элемент , и JavaScript перенаправления используют DOM .

HTML перенаправления

HTTP перенаправления более предпочтительный способ создания перенаправлений, но, иногда, у веб-разработчиков нету контроля над сервером или возможности настроить его. Для таких особых случаев, разработчики могут создать HTML страницу с элементом и установить атрибуту http-equiv значение refresh в блоке элемент предоставляет общую информацию (метаданные) о документе, которая включает в себя заголовок и ссылки на скрипты и стили."> . Когда страница отображается, браузер найдет этот элемент и перейдет на указанную страницу.

ServerName example.com Redirect / http://www.example.com

URL http://example.com/ будет переенаправлен к http://www.example.com/ (но не к http://example.com/other.html)

Redirect_Match делает то же, но использует регулярное выражение, чтобы определить множество URL адресов, которые подпадут под эффект:

RedirectMatch ^/images/(.*)$ http://images.example.com/$1

Все документы в папке images/ будут перенаправляться к другому домену.

Если вы не хотите устанавливать временное перенаправление, дополнительный параметр (используйте или код статуса HTTP, или ключевое слово permanent) может использоваться чтобы установить другое перенаправление:

Redirect permanent / http://www.example.com Redirect 301 / http://www.example.com

Также модуль mod_rewrite может использоваться для создания перенаправлений. Они более гибкие, но сложнее в использовании.

Nginx

В Nginx, вы создаете особый серверный блок для контента, который вы хотите перенаправлять:

Server { listen 80; server_name example.com; return 301 $scheme://www.example.com$request_uri; }

Чтобы применить перенаправления к папке или подмножеству страниц, используйте директиву rewrite:

Rewrite ^/images/(.*)$ http://images.example.com/$1 redirect; rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;

IIS

В IIS, вы используете элемент для настройки перенаправлений.

Циклы перенаправлений

Циклы перенаправлений случаются когда за успешным перенаправлением следует другое, которое уже было выполнено. Другими словами, существует такой цикл, который никогда не закончится и в конечном счете ни одна страница не будет найдена.

В большинстве случаев это проблема сервера, и если сервер не может обнаружить её, то отправит код статуса Internal Server Error . Если вы встретите такую ошибку вскоре после редактирования настроек сервера, то это скорее всего цикл перенаправлений.

В случае, когда сервер не может обнаружить его: цикл перенаправлений может распространиться на несколько серверов, каждый из которых не имеет полной картины происходящего. В этом случае, браузеры покажут сообщение об ошибке. Firefox выведет:

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

тогда, как Chrome:

This Webpage has a redirect loop

В обоих случаях, пользователь не может ничего сделать (в отличие от ошибки на стороне клиента, например, несоответствие файлов куки или кеша).

Важно избегать циклов перенаправлений, так как они полностью нарушают работу пользователя.