HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) был разработан как основа World Wide Web.
Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.
Структура HTTP-запроса
HTTP-запрос состоит из заголовка запроса и тела запроса, разделенных пустой строкой. Тело запроса может отсутствовать.
Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.
Запрос в главной строке состоит из трех частей, разделенных пробелами:
Метод (иначе говоря, команда HTTP):
GET - запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.
HEAD - запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.
POST - этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.
PUT - разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.
Ресурс - это путь к определенному файлу на сервере, который клиент хочет получить (или разместить - для метода PUT). Если ресурс - просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.
Версия протокола -версия протокола HTTP, с которой работает клиентская программа.
Таким образом, простейший HTTP-запрос может выглядеть следующим образом:
Здесь запрашивается корневой файл из корневой директории web-сервера.
Строки после главной строки запроса имеют следующий формат:
Параметр: значениe .
Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).
Перечислю некоторые наиболее употребительные параметры HTTP-запроса:
Connection
(соединение)- может принимать значения Keep-Alive и close.
Keep-Alive ("оставить в живых") означает, что после выдачи данного документа
соединение с сервером не разрывается, и можно выдавать еще запросы.
Большинство браузеров работают именно в режиме Keep-Alive, так как он
позволяет за одно соединение с сервером "скачать" html-страницу и рисунки
к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до
первой ошибки или до явного указания в очередном запросе Connection: close.
close ("закрыть") - соединение закрывается после ответа на данный запрос.
User-Agent - значением является "кодовое обозначение" браузера, например:
Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)
Accept - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.
Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.
Referer - URL, с которого перешли на этот ресурс.
Host - имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.
Accept-Language - поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.
Формат HTTP-ответа
Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.
Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.
Основная строка запроса состоит из 3-х полей, разделенных пробелами:
Версия протокола - аналогичен соответствующему параметру запроса.
Код ошибки - кодовое обозначение "успешности" выполнения запроса. Код 200 означает "все нормально" (OK).
Словесное описание ошибки - "расшифровка" предыдущего кода. Например для 200 это OK, для 500 - Internal Server Error.
Наиболее употребительные параметры http-ответа:
Connection
- аналогичен соответствующему параметру запроса.
Если сервер не поддерживает Keep-Alive (есть и такие), то значение
Connection в ответе всегда close.
Поэтому, на мой взгляд, правильной тактикой браузера является следующая:
1. выдать в запросе Connection: Keep-Alive;
2. о состоянии соединения судить по полю Connection в ответе.
Content-Type ("тип содержимого") - содержит обозначение типа содержимого ответа.
В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.
Некоторые типы содержимого:
text/html - текст в формате HTML (веб-страница);
text/plain - простой текст (аналогичен "блокнотовскому");
image/jpeg - картинка в формате JPEG;
image/gif - то же, в формате GIF;
application/octet-stream - поток "октетов" (т.е. просто байт) для записи
на диск.
На самом деле типов содержимого гораздо больше.
Content-Length ("длина содержимого") - длина содержимого ответа в байтах.
Last-Modified ("Модифицирован в последний раз") - дата последнего изменения документа.
Часто ли у посетителей Вашего сайта (интернет-магазина, или другим видом обработки персональных данных) возникают сомнения: можно ли доверять данному ресурсу?
В далеком 1994 году ребята из Netscape Communications позаботились об особо подозрительных пользователях всемирной сети и придумали волшебную штуку — HTTPS.
Что такое HTTPS?
HTTPS (HyperText Transfer Protocol Secure) - расширение протокола HTTP, для поддержки шифрования в целях защиты и повышения уровня безопасности персональных данных пользователей. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.
Да-да, довольно сложно и не очень понятно. .
Если говорить более простым языком, протокол шифрует важные данные, вводимые пользователем на сайте (например, данные паспорта, номер карты и т.д), а далее эта информация передается по открытым канал (интернет-провайдер, хосты) и поступает на нужный сервис.
Например, пользователь Сбербанк.Онлайн отправил данные в текстовом формате (текст “123”) через сайт с https. К этим данным на сервере отправителя (???) прикрепляется ключ, шифрующий введенные данные. Таким образом, отправленные данные невозможно перехватить с помощью сторонних программ.
Данные в протоколе HTTPS передаются поверх криптографических протоколов SSL или TLS. Именно эти протоколы поддерживают зашифрованное соединение между сервером и браузером пользователя .
Что думают поисковики об https?
Гугл однозначно за шифрование трафика. И в обновленной 56 версии Google Chrome сайты уже помечены как надежный (на https) и ненадежный (на http):
При этом справедливо отметить, что переход на безопасный протокол — далеко не первостепенный фактор ранжирования. Однако нет сомнений, что в дальнейшем вес https будет только расти.
Что касается Яндекса — официальной информации по этому поводу нет, но при этом все сервисы компании уже перешли на защищенный протокол.
Очевидно, что на данный момент переход на безопасный протокол не сдвинет Ваш сайт в выдаче на ряд позиций вверх и что с точки зрения ранжирования это скорее работа на перспективу. Однако нужно понимать, что главное преимущество протокола https — безопасность данных ваших посетителей
. Поэтому для повышения доверия к вашему сайту и компании в целом переход на безопасный протокол будет крайне полезен.
3 этапа перехода сайта с http на https
Шаг 1: cертификат безопасности SSL
Приобрести и настроить сертификат безопасности (SSL), выданный удостоверяющим центром
SSL (Secure Socket Layer) — сертификат, это индивидуальная цифровая подпись вашего домена. Вы можете выбрать любой из 5 видов сертификата безопасности :
Самоподписанный
Из названия понятно, что его может создать любой пользователь на домен или IP адрес, т.е. подтверждения от удостоверяющего центра здесь нет, выдает и подписывает сам пользователь .
- бесплатный;
- можно создать неограниченное количество раз;
- при переходе будет уведомление, не является подлинным
- имеет короткий срок службы;
- некоторые браузеры могут не поддерживать и страница не будет открываться;
- не распространяется на поддомены;
- не поддерживает URL на кирилице.
Domain Validation (Валидация по домену)
Один из самых распространенных сертификатов начального уровня .
- готовность в течении пары часов
- подходит для большинства сайтов
- распространенный, легко доступен
- невысокая стоимость
- выдается на один домен (при смене придется покупать еще раз)
- действует от года до 3 лет
- минимум личных данных на сайте
- не поддерживает URL на кирилице
Бизнес уровень, более защищенный, сертификат является универсальным и чаще всего им пользуются интернет-магазины, сайты услуг, порталы. Выдается исключительно юридическим лицам , при оформлении происходит проверка домена и организации.
- высокий уровень защиты
- срок выдачи от 3 до 10 раб дней
- стоимость дороже
Сертификаты высокого статуса для средних и крупных компаний его используют банки , платежные системы, крупные сервисы, госструктуры т.д
- среди SSL-сертификатов самый высокий класс защиты
- прибавляется вес и авторитетность ресурса
- высокая стоимость
Wildcsrd (поддомен)
Надстройка для сертификатов, защита всех прямых поддоменов указываемых
Шаг 2: настройка данных в системах аналитики
- Яндекс.Вебмастер. Необходимо на старом домене с указанием новой директивы host и указать главное зеркало. У ведомить поисковую систему о новом протоколе.
- Яндекс.Вебмастер — Индексирование — Переезд сайта.
- Только после того как в Яндекс.Вебмастер появится соответствующие изменения настраиваем 301 редирект (важно только после того как появится уведомление, что сайт доступен на https настраиваем 301 редирект)
- В Google Analytics меняем представителя с http // на https
Шаг 3: обновляем внутренние ссылки
Старые ссылки, увы, не будут работать, меняем ссылки в контенте, в стилях CSS, в скриптах, шаблонах на https . Были http//site.ru станут https//site.ru. Существует большое количество утилит, плагинов для автоматической замены старых ссылок.
На WP, например, можно воспользоваться плагином Velvet Blues Update URLs
Обновляем изображения (при необходимости). Рекомендуем прописывать и ссылки и путь к изображениям без указания домена, а в формате /uplods/photo/sertifikat https)
Карту сайта , файл . Проверяем, чтобы был указан исключительно протокол https.
Подведем итог:
Чтобы улучшить доверие пользователей и поисковых систем к вашему сайту с помощью переезда домена на https, нужно технически реализовать 3 вещи:
- Получить и настроить сертификат безопасности (SSL), подходящий вашему сайту.
- Дать понять поисковым системам что ваш сайт изменил адрес (переехал с http на https).
- Произвести внутреннюю оптимизацию сайта с учетом нового доменного имени.
Столкнулись с трудностями при переезде с http на https? Или хотите их избежать? Закажите у нас seo-аудит и мы поможем Вам со сменой домена.
Подпишись и следи за выходом новых статей в нашем
В связи с массовым переходом сайтов на 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 , который будет установлен там, где необходимо осуществить редирект.
