Http протокол структура методы ошибки

Большинство используемых нами веб- и мобильных приложений постоянно взаимодействуют с глобальной сетью. Почти все подобные коммуникации совершаются с помощью запросов по протоколу HTTP. Рассказываем о них подробнее.

Базово о протоколе HTTP

HTTP (HyperText Transfer Protocol, дословно — «протокол передачи гипертекста») представляет собой протокол прикладного уровня, используемый для доступа к ресурсам Всемирной Паутины. Под термином гипертекст следует понимать текст, в понятном для человека представлении, при этом содержащий ссылки на другие ресурсы.

Данный протокол описывается спецификацией RFC 2616. На сегодняшний день наиболее распространенной версией протокола является версия HTTP/2, однако нередко все еще можно встретить более раннюю версию HTTP/1.1.

В обмене информацией по HTTP-протоколу принимают участие клиент и сервер. Происходит это по следующей схеме: 

1. Клиент запрашивает у сервера некоторый ресурс.
2. Сервер обрабатывает запрос и возвращает клиенту ресурс, который был запрошен.

По умолчанию для коммуникации по HTTP используется порт 80, хотя вместо него может быть выбран и любой другой порт. Многое зависит от конфигурации конкретного веб-сервера.

Подробнее о протоколе HTTP читайте по ссылке →

HTTP-сообщения: запросы и ответы

Данные между клиентом и сервером в рамках работы протокола передаются с помощью HTTP-сообщений. Они бывают двух видов:

• Запросы (HTTP Requests) — сообщения, которые отправляются клиентом на сервер, чтобы вызвать выполнение некоторых действий. Зачастую для получения доступа к определенному ресурсу. Основой запроса является HTTP-заголовок.
• Ответы (HTTP Responses) — сообщения, которые сервер отправляет в ответ на клиентский запрос.

Само по себе сообщение представляет собой информацию в текстовом виде, записанную в несколько строчек.

В целом, как запросы HTTP, так и ответы имеют следующую структуру:

1. Стартовая строка (start line) — используется для описания версии используемого протокола и другой информации — вроде запрашиваемого ресурса или кода ответа. Как можно понять из названия, ее содержимое занимает ровно одну строчку.
2. HTTP-заголовки (HTTP Headers) — несколько строчек текста в определенном формате, которые либо уточняют запрос, либо описывают содержимое тела сообщения.
3. Пустая строка, которая сообщает, что все метаданные для конкретного запроса или ответа были отправлены.
4. Опциональное тело сообщения, которое содержит данные, связанные с запросом, либо документ (например HTML-страницу), передаваемый в  ответе.

Рассмотрим атрибуты HTTP-запроса подробнее.

Стартовая строка

Стартовая строка HTTP-запроса состоит из трех элементов:

1. Метод HTTP-запроса (method, реже используется термин verb). Обычно это короткое слово на английском, которое указывает, что конкретно нужно сделать с запрашиваемым ресурсом. Например, метод GET сообщает серверу, что пользователь хочет получить некоторые данные, а POST — что некоторые данные должны быть помещены на сервер.
2. Цель запроса. Представлена указателем ресурса URL, который состоит из протокола, доменного имени (или IP-адреса), пути к конкретному ресурсу на сервере. Дополнительно может содержать указание порта, несколько параметров HTTP-запроса и еще ряд опциональных элементов.
3. Версия используемого протокола (либо HTTP/1.1, либо HTTP/2), которая определяет структуру следующих за стартовой строкой данных.

В примере ниже стартовая строка указывает, что в качестве метода используется GET, обращение будет произведено к ресурсу /index.html, по версии протокола HTTP/1.1:

Разберемся с каждым из названных элементов подробнее.

Методы

Методы позволяют указать конкретное действие, которое мы хотим, чтобы сервер выполнил, получив наш запрос. Так, некоторые методы позволяют браузеру (который в большинстве случаев является источником запросов от клиента) отправлять дополнительную информацию в теле запроса — например, заполненную форму или документ.

Ниже приведены наиболее используемые методы и их описание:

Разберемся с каждым из названных элементов подробнее.

URL

Получение доступа к ресурсам по HTTP-протоколу осуществляется с помощью указателя URL (Uniform Resource Locator). URL представляет собой строку, которая позволяет указать запрашиваемый ресурс и еще ряд параметров.

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

Поле Scheme используется для указания используемого протокола, всегда сопровождается двоеточием и двумя косыми чертами (://).

Host указывает местоположение ресурса, в нем может быть как доменное имя, так и IP-адрес.

Port, как можно догадаться, позволяет указать номер порта, по которому следует обратиться к серверу. Оно начинается с двоеточия (:), за которым следует номер порта. При отсутствии данного элемента номер порта будет выбран по умолчанию в соответствии с указанным значением Scheme (например, для http:// это будет порт 80).

Далее следует поле Path. Оно указывает на ресурс, к которому производится обращение. Если данное поле не указано, то сервер в большинстве случаев вернет указатель по умолчанию (например index.html).

Поле Query String начинается со знака вопроса (?), за которым следует пара «параметр-значение», между которыми расположен символ равно (=). В поле Query String могут быть переданы несколько параметров с помощью символа амперсанд (&) в качестве разделителя.

Не все компоненты необходимы для доступа к ресурсу. Обязательно следует указать только поля Scheme и Host.

Версии HTTP

Раз уж мы упомянули версию протокола как элемента стартовой строки, то стоит сказать об основных отличиях версий HTTP/1.X от HTTP/2.X.

Последняя стабильная, наиболее стандартизированная версия протокола первого поколения (версия HTTP/1.1) вышла в далеком 1997 году. Годы шли, веб-страницы становились сложнее, некоторые из них даже стали приложениями в том виде, в котором мы понимаем их сейчас. Кроме того, объем медиафайлов и скриптов, которые добавляли интерактивность страницам, рос. Это, в свою очередь, создавало перегрузки в работе протокола версии HTTP/1.1.

Стало очевидно, что у HTTP/1.1 есть ряд значительных недостатков:

• Заголовки, в отличие от тела сообщения, передавались в несжатом виде.
• Часто большая часть заголовков в сообщениях совпадала, но они продолжали передаваться по сети.
• Отсутствовала возможность так называемого мультиплексирования — механизма, позволяющего объединить несколько соединений в один поток данных. Приходилось открывать несколько соединений на сервере для обработки входящих запросов.

С выходом HTTP/2 было предложено следующее решение: HTTP/1.X-сообщения разбивались на так называемые фреймы, которые встраивались в поток данных.

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

Единственное о чем стоит сказать в завершение темы: HTTP/2 перестал быть текстовым протоколом, а стал работать с «сырой» двоичной формой данных. Это ограничивает чтение и создание HTTP-сообщений «вручную». Однако такова цена за возможность реализации более совершенной оптимизации и повышения производительности.

Заголовки

HTTP-заголовок представляет собой строку формата «Имя-Заголовок:Значение», с двоеточием(:) в качестве разделителя. Название заголовка не учитывает регистр, то есть между Host и host, с точки зрения HTTP, нет никакой разницы. Однако в названиях заголовков принято начинать каждое новое слово с заглавной буквы. Структура значения зависит от конкретного заголовка. Несмотря на то, что заголовок вместе со значениями может быть достаточно длинным, занимает он всего одну строчку.

В запросах может передаваться большое число различных заголовков, но все их можно разделить на три категории:

1. Общего назначения, которые применяются ко всему сообщению целиком.
2. Заголовки запроса уточняют некоторую информацию о запросе, сообщая дополнительный контекст или ограничивая его некоторыми логическими условиями.
3. Заголовки представления, которые описывают формат данных сообщения и используемую кодировку. Добавляются к запросу только в тех случаях, когда с ним передается некоторое тело.

Ниже можно видеть пример заголовков в запросе:

Самые частые заголовки запроса

Тело запроса

Завершающая часть HTTP-запроса — это его тело. Не у каждого HTTP-метода предполагается наличие тела. Так, например, методам вроде GET, HEAD, DELETE, OPTIONS обычно не требуется тело. Некоторые виды запросов  могут отправлять данные на сервер в теле запроса: самый распространенный из таких методов — POST.

Ответы HTTP

HTTP-ответ является сообщением, которое сервер отправляет клиенту в ответ на его запрос. Его структура равна структуре HTTP-запроса: стартовая строка, заголовки и тело.

Строка статуса (Status line)

Стартовая строка HTTP-ответа называется строкой статуса (status line). На ней располагаются следующие элементы:

1. Уже известная нам по стартовой строке запроса версия протокола (HTTP/2 или HTTP/1.1).
2. Код состояния, который указывает, насколько успешно завершилась обработка запроса.
3. Пояснение — короткое текстовое описание к коду состояния. Используется исключительно для того, чтобы упростить понимание и восприятие человека при просмотре ответа.

Коды состояния и текст статуса

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

Полный список кодов состояния доступен в спецификации к протоколу, ниже приведены только самые распространенные коды ответов:

Помимо основных кодов состояния, описанных в стандарте, существуют и коды состояния, которые объявляются крупными сетевыми провайдерами и серверными платформами. Так, коды состояния, используемые Selectel, можно посмотреть здесь.

Заголовки ответа

Response Headers, или заголовки ответа, используются для того, чтобы уточнить ответ, и никак не влияют на содержимое тела. Они существуют в том же формате, что и остальные заголовки, а именно  «Имя-Значение» с двоеточием (:) в качестве разделителя.

Ниже приведены наиболее часто встречаемые в ответах заголовки:

Тело ответа

Последней частью ответа является его тело. Несмотря на то, что у большинства ответов тело присутствует, оно не является обязательным. Например, у кодов «201 Created» или «204 No Content» тело отсутствует, так как достаточную информацию для ответа на запрос они передают в заголовке.

Безопасность HTTP-запросов, или что такое HTTPs

HTTP является расширяемым протоколом, который предоставляет огромное количество возможностей, а также поддерживает передачу всевозможных типов файлов. Однако, вне зависимости от версии, у него есть один существенный недостаток, который можно заметить если перехватить отправленный HTTP-запрос:

Да, все верно: данные передаются в открытом виде. HTTP сам по себе не предоставляет никаких средств шифрования.

Но как же тогда работают различные банковские приложения, интернет-магазины, сервисы оплаты услуг и прочие приложения, в которых циркулирует чувствительная информация пользователей?

Время рассказать про HTTPs! 

HTTPs (HyperText Transfer Protocol, secure) является расширением HTTP-протокола, который позволяет шифровать отправляемые данные, перед тем как они попадут на транспортный уровень. Данный протокол по умолчанию использует порт 443.

Теперь если мы перехватим не HTTP , а HTTPs-запрос, то не увидим здесь ничего интересного:

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

Три межсетевых экрана для любых потребностей бизнеса.

Если хотите подробнее узнать о деталях работы протокола, читайте статью в нашем блоге →

Как отправить HTTP-запрос и прочитать его ответ

Теория это, конечно, отлично, но ничего так хорошо не закрепляет материал, как практика

Мы рассмотрим несколько способов, как написать HTTP-запрос в браузер, послать HTTP-запрос на сервер и получить ответ:

1. Инструменты разработчика в браузере. 
2. Утилита cURL.

Инструменты разработчика

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

По нажатию комбинации клавиш [Ctrl+Shift+I] или просто [F12] в подавляющем большинстве современных браузеров у нас откроется окно инструментов разработчика, которая представляет собой панель с несколькими вкладками. Нужная нам вкладка обычно называется Network. Перейдем в нее, а в адресной строке введем URL того сайта, на который хотим попасть. В качестве примера воспользуемся сайтом блога Selectel — https://selectel.ru/blog/.

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

Не спешите пугаться. Это всего лишь список ресурсов, которые нужны для правильного отображения и работы сайта.

Нажав на любой из них, мы можем увидеть детали обработки отправленного запроса:

В данном запросе, например:

• URL, к которому было совершено обращение — https://selectel.ru/blog,
• Метод, который был использован в запросе — GET,
• И в качестве кода возврата сервер вернул нам страницу с кодом статуса — 200 OK 

Утилита cURL

Следующий инструмент, с помощью которого мы сможем послать запрос на тот или иной сервер, это утилита cURL.

cURL (client URL) является небольшой утилитой командной строки, которая позволяет работать с HTTP и рядом других протоколов.

Для отправки запроса и получения ответа мы можем воспользоваться флагом -v и указанием URL того ресурса, который мы хотим получить. «Схему» HTTP-запроса можно увидеть на скрине ниже:

После запуска утилита выполняет: 

• подключение к серверу, 
• самостоятельно разрешает все вопросы, необходимые для отправки запроса по HTTPs, 
• отправляет запрос, содержимое которого мы можем видеть благодаря флагу -v,
•  принимая ответ от сервера, отображает его в командной строке «как-есть».  

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

Заключение

HTTP представляет собой расширяемый протокол прикладного уровня, на котором работает весь веб-сегмент интернета. В данной статье мы рассмотрели принцип его работы, структуру, «компоненты» HTTP-запросов. Коснулись вопросов отличия версий протокола, HTTPs  — его расширения, добавляющего шифрование. Разобрали устройство запроса, поняли, как можно отправить HTTP-запрос и получить ответ от сервера.

Уровень сложности
Простой

Время на прочтение
9 мин

Количество просмотров 27K

Привет! Меня зовут Ивасюта Алексей, я техлид команды Bricks в Авито в кластере Architecture. Я решил написать цикл статей об истории и развитии HTTP, рассмотреть каждую из его версий и проблемы, которые они решали и решают сейчас. 

Весь современный веб построен на протоколе HTTP. Каждый сайт использует его для общения клиента с сервером. Между собой сервера тоже часто общаются по этому протоколу. На данный момент существует четыре его версии и все они до сих пор используются. Поэтому статьи будут полезны инженерам любых уровней и специализаций, и помогут систематизировать знания об этой важной технологии.

Что такое HTTP

HTTP — это гипертекстовый протокол передачи данных прикладного уровня в сетевой модели OSI. Его представил миру Тим Бернерс-Ли в марте 1991 года. Главная особенность HTTP — представление всех данных в нём в виде простого текста. Через HTTP разные узлы в сети общаются между собой. Модель клиент-серверного взаимодействия классическая: клиент посылает запрос серверу, сервер обрабатывает запрос и возвращает ответ клиенту. Полученный ответ клиент обрабатывает и решает: прекратить взаимодействие или продолжить отправлять запросы.

Ещё одна особенность: протокол не сохраняет состояние между запросами. Каждый запрос от клиента для сервера — отдельная транзакция. Когда поступают два соседних запроса, сервер не понимает, от одного и того же клиента они поступили, или от разных. Такой подход значительно упрощает построение архитектуры веб-серверов.

Как правило, передача данных по HTTP осуществляется через открытое TCP/IP-соединение¹. Серверное программное обеспечение по умолчанию обычно использует TCP-порт 80 для работы веб-сервера, а порт 443 — для HTTPS-соединений.

HTTPS (HTTP Secure) — это надстройка над протоколом HTTP, которая поддерживает шифрование посредством криптографических протоколов SSL и TLS. Они шифруют отправляемые данные на клиенте и дешифруют их на сервере. Это защищает данные от чтения злоумышленниками, даже если им удастся их перехватить.  

HTTP/0.9

В 1991 году была опубликована первая версия протокола с названием HTTP/0.9. Эта реализация была проста, как топор. От интернет-ресурса того времени требовалось только загружать запрашиваемую HTML-страницу и HTTP/0.9 справлялся с этой задачей. Обычный запрос к серверу выглядел так:

GET /http-spec.html

В протоколе был определен единственный метод GET и и указывался путь к ресурсу. Так пользователи получали страничку. После этого открытое соединение сразу закрывалось. 

HTTP/1.0

Годы шли и интернет менялся. Стало понятно, что нужно не только получать странички от сервера, но и отправлять ему данные. В 1996 году вышла версия протокола 1.0.

Что изменилось:

1. В запросе теперь надо было указывать версию протокола. Так сервер мог понимать, как обрабатывать полученные данные.

2. В ответе от сервера появился статус завершения обработки запроса.

3. К запросу и ответу добавился новый блок с заголовками.

4. Добавили поддержку новых методов:

• HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа. Так можно получить только заголовки, без самого ресурса.

• POST добавляет сущность к определённому ресурсу. Часто вызывает изменение состояния или побочные эффекты на сервере. Например, так можно отправить запрос на добавление нового поста в блог.

Структура запроса

Простой пример запроса:

GET /path HTTP/1.0
Content-Type: text/html; charset=utf-8
Content-Length: 4
X-Custom-Header: value

test

В первой строчке указаны метод запроса — GET, путь к ресурсу — /path и версия протокола —  HTTP/1.0.

Далее идёт блок заголовков. Заголовки — это пары ключ: значение, каждая из которых записывается с новой строки и разделяется двоеточием. Они передают дополнительные данные и настройки от клиента к серверу и обратно. 

HTTP — это текстовый протокол, поэтому и все данные передаются в виде текста. Заголовки можно отделить друг от друга только переносом строки. Нельзя использовать запятые, точку с запятой, или другие разделители. Всё, что идет после имени заголовка с двоеточием и до переноса строки, будет считаться значением заголовка².

В примере серверу передали три заголовка: 

1. Content-Type — стандартный заголовок. Показывает, в каком формате будут передаваться данные в теле запроса или ответа.

2. Content-Length — сообщает длину контента в теле запроса в байтах.

3. X-Custom-Header — пользовательские заголовки, начинающиеся с X- с произвольными именем. Через них реализуется специфическая логика обработки для конкретного сервера. Если веб-сервер не поддерживает такие заголовки, то он проигнорирует их.

После блока заголовков идёт тело запроса, в котором передается текст test. 

А так может выглядеть ответ от сервера:

HTTP/1.1 200 OK
Date: Thu, 29 Jul 2021 19:20:01 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2
Connection: close
Server: gunicorn/19.9.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

OK

В первой строке — версия протокола и статус ответа, например, 200 ОК. Далее идут заголовки ответа. После блока заголовков — тело ответа, в котором записан текст OK. 

Статусы ответов

Клиенту зачастую недостаточно просто отправить запрос на сервер. Во многих случаях надо дождаться ответа и понять, как сервер обработал запрос. Для этого были придуманы статусы ответов. Это трёхзначные числовые коды с небольшими текстовыми обозначениями. Их можно увидеть в терминале или браузере. Сами коды делятся на 5 классов:

• Информационные ответы: коды 100–199

• Успешные ответы: коды 200–299

• Редиректы: коды 300–399

• Клиентские ошибки: коды 400–499

• Серверные ошибки: коды 500–599

Мы рассмотрим основные коды, которые чаще всего встречаются в реальных задачах. С остальными более подробно можно ознакомиться в реестре кодов состояния HTTP.

Информационные ответы

100 Continue — промежуточный ответ. Он указывает, что запрос успешно принят.  Клиент может продолжать присылать запросы или проигнорировать этот ответ, если запрос был завершён.

Примечание

Этот код ответа доступен с версии HTTP/1.1.

101 Switching Protocol присылается в ответ на запрос, в котором есть заголовок Upgrade. Это означает, что сервер переключился на протокол, который был указан в заголовке. Такая методика используется, например, для переключения на протокол Websocket.

102 Processing — запрос получен сервером, но его обработка ещё не завершена.

Успешные ответы

200 OK — запрос принят и корректно обработан веб-сервером.

201 Created — запрос корректно обработан и в результате был создан новый ресурс. Обычно он присылается в ответ на POST запрос.

Редиректы

301 Moved Permanently — запрашиваемый ресурс на постоянной основе переехал на новый адрес. Тогда новый путь к ресурсу указывается сервером в заголовке Location ответа.

Примечание

Клиент может изменить метод последующего запроса с POST на GET.

302 Found — указывает, что целевой ресурс временно доступен по другому URl. Адрес перенаправления может быть изменен в любое время, а клиент должен продолжать использовать действующий URI для будущих запросов. Тогда временный путь к ресурсу указывается сервером в заголовке Location ответа.

Примечание

Клиент может изменить метод последующего запроса с POST на GET.

307 Temporary Redirect — имеет то же значение, что и код 302, за исключением того, что клиент не может менять метод последующего запроса.

308 Permanent Redirect — имеет то же значение, что и код 301, за исключением того, что клиент не может менять метод последующего запроса.

Клиентские ошибки

400 Bad Request — запрос от клиента к веб-серверу составлен некорректно. Обычно это происходит, если клиент не передаёт необходимые заголовки или параметры.

401 Unauthorized — получение запрашиваемого ресурса доступно только аутентифицированным пользователям.

403 Forbidden — у клиента не хватает прав для получения запрашиваемого ресурса. Например, когда обычный пользователь сайта пытается получить доступ к панели администратора.

404 Not Found — сервер не смог найти запрашиваемый ресурс.

405 Method Not Allowed — сервер знает о существовании HTTP-метода, который был указан в запросе, но не поддерживает его. В таком случае сервер должен вернуть список поддерживаемых методов в заголовке Allow ответа.

Серверные ошибки

500 Internal Server Error — на сервере произошла непредвиденная ошибка.

501 Not Implemented — метод запроса не поддерживается сервером и не может быть обработан.

502 Bad Gateway — сервер, действуя как шлюз или прокси, получил недопустимый ответ от входящего сервера, к которому он обращался при попытке выполнить запрос.

503 Service Unavailable — сервер не готов обработать запрос (например, из-за технического обслуживания или перегрузки). Обратите внимание, что вместе с этим ответом должна быть отправлена ​​удобная страница с объяснением проблемы. Этот ответ следует использовать для временных условий, а HTTP-заголовок Retry-After по возможности должен содержать расчётное время до восстановления службы.

504 Gateway Timeout — этот ответ об ошибке выдается, когда сервер действует как шлюз и не может получить ответ за отведенное время.

505 HTTP Version Not Supported — версия HTTP, используемая в запросе, не поддерживается сервером.

В HTTP из всего диапазона кодов используется совсем немного. Те коды, которые не используются для задания определенной логики в спецификации, являются неназначенными и могут использоваться веб-серверами для определения своей специфической логики. Это значит, что вы можете, например, придать коду 513 значение «Произошла ошибка обработки видео», или любое другое. Неназначенные коды вы можете посмотреть в реестре кодов состояния HTTP.³

Тело запроса и ответа

Тело запроса опционально и всегда отделяется от заголовков пустой строкой. А как понять, где оно заканчивается? Всё кажется очевидным: где кончается строка, там и заканчивается тело. Однако, два символа переноса строки в HTTP означают конец запроса и отправляют его на сервер. Как быть, если мы хотим передать в теле текст, в котором есть несколько абзацев с разрывами в две строки?

POST /path HTTP/1.1
Host: localhost

Первая строка


Вторая строка после разрыва

По логике работы HTTP соединение отправится сразу после второй пустой строки и сервер получит в качестве данных только строку Первая строка. Описанную проблему решает специальный заголовок Content-Length. Он указывает на длину контента в байтах. Обычно клиенты (например, браузеры) автоматически считают длину передаваемых данных и добавляют к запросу заголовок с этим значением. Когда сервер получит запрос, он будет ожидать в качестве контента ровно столько байт, сколько указано в заголовке.

Однако, этого недостаточно для того, чтобы передать данные на сервер. Поведение зависит от реализации сервера, но для большинства из них необходимо также передать заголовок Content-Type. Он указывает на тип передаваемых данных. В качестве значения для этого заголовка используют MIME-типы.⁴

MIME (Multipurpose Internet Mail Extensions, многоцелевые расширения интернет-почты) — стандарт, который является частью протокола HTTP. Задача MIME — идентифицировать тип содержимого документа по его заголовку. К примеру, текстовый файл имеет тип text/plain, а HTML-файл — text/html.

Для передачи данных в формате обычного текста надо указать заголовок Content-Type: text/plain, а для JSON — Content-Type: application/json.

Можно ли передать тело с GET-запросом?

Популярный вопрос на некоторых собеседованиях: «Можно ли передать тело с GET-запросом?». Правильный ответ — да. Тело запроса не зависит от метода. В стандарте не описана возможность принимать тело запроса у GET-метода, но это и не запрещено. Технически вы можете отправить данные в теле, но скорее всего веб-сервер будет их игнорировать.

Представим, что на абстрактном сайте есть форма аутентификации пользователя, в которой есть всего два поля: email и пароль. 

Если пользователь ввёл данные и нажал на кнопку «Войти», то данные из полей формы должны попасть на сервер. Самым простым и распространенным форматом передачи таких данных будет MIME application/x-www-form-urlencoded. В нем все поля передаются в одной строке в формате ключ=значение и разделяются знаком &. 

Запрос на отправку данных будет выглядеть так: 

POST /login HTTP/1.0
Host: example.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 26
login=user&password=qwerty

Тут есть небольшая особенность. Как понять, где заканчивается ключ и начинается его значение, если в пароле будет присутствовать знак «=» ?

POST /login HTTP/1.0
Host: example.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 26
login=user&password=123=45

В этом случае сервер не сможет понять, как разбить строку на параметры и их значения. На самом деле значения кодируются при помощи механизма url encoding.⁵ При использовании этого механизма знак «=» будет преобразован в код %3D .

Тогда наш запрос приобретёт такой вид:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 28

login=user&password=123%3D45

Query string

Данные на сервер можно передавать через тело запроса и через так называемую строку запроса Query String. Это параметры формата ключ=значение, которые располагаются в пути к ресурсу:

GET /files?key=value&key2=value2 HTTP/1.0

При этом параметры можно передавать прямо от корня домена:

GET /?key=value&key2=value2 HTTP/1.0

Query String имеет такой же формат, как и тело запроса с MIME application/x-www-form-urlencoded, только первая пара значений отделяется от адреса вопросительным знаком.

Некоторые инженеры ошибочно полагают, что Query String являются параметрами GET-запроса и даже называют их GET-параметрами, но на самом деле это не так. Как и тело запроса, Query String не имеет привязки к HTTP-методам и может передаваться с любым типом запросов.

Обычно параметры Query String используются в GET-запросах, чтобы конкретизировать получаемый ресурс. Например, можно получить на сервере список файлов, имена которых будут начинаться с переданного значения. 

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

На этом я закончу говорить про версию протокола 1.0, структуру ответов и запросов. В следующей статье я расскажу, что такое Cookies, для чего нужен CORS и как это всё работает. А пока напоследок оставлю полезные ссылки, которые упомянул в тексте:

1. Основы TCP/IP

2. Заголовки HTTP

3. Реестр кодов состояния HTTP

4. MIME типы

5. Алгоритм кодирования URL encoding

Следующая статья: Ультимативный гайд по HTTP. Cookies и CORS

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) — символьно-ориентированный клиент-серверный протокол прикладного уровня без сохранения состояния, используемый сервисом World Wide Web.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier – уникальный идентификатор ресурса) в запросе клиента. Основными ресурсами являются хранящиеся на сервере файлы, но ими могут быть и другие логические (напр. каталог на сервере) или абстрактные объекты (напр. ISBN). Протокол HTTP позволяет указать способ представления (кодирования) одного и того же ресурса по различным параметрам: mime-типу, языку и т. д. Благодаря этой возможности клиент и веб-сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

100 Continue (Продолжать)
101 Switching Protocols (Переключение протоколов)
102 Processing (Идёт обработка)

200 OK (Успешно).
201 Created (Создано)
202 Accepted (Принято)
204 No Content (Нет содержимого)
206 Partial Content (Частичное содержимое)

300 Multiple Choices (Множественный выбор)
301 Moved Permanently (Перемещено навсегда)
304 Not Modified (Не изменялось)

401 Unauthorized (Неавторизован)
402 Payment Required (Требуется оплата)
403 Forbidden (Запрещено)
404 Not Found (Не найдено)
405 Method Not Allowed (Метод не поддерживается)
406 Not Acceptable (Не приемлемо)
407 Proxy Authentication Required (Требуется аутентификация прокси)

500 Internal Server Error (Внутренняя ошибка сервера)
502 Bad Gateway (Плохой шлюз)
503 Service Unavailable (Сервис недоступен)
504 Gateway Timeout (Шлюз не отвечает)

Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 51
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive

200 OK

http://www.example.org/

GET http://www.example.org/ HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive

HTTP/1.0 302 Moved Temporarily
Date: Thu, 03 Mar 2011 06:48:28 GMT
Location: http://www.iana.org/domains/example/
Server: BigIP
Content-Length: 0
X-Cache: MISS from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive
----------------------------------------------------------
http://www.iana.org/domains/example/

GET http://www.iana.org/domains/example/ HTTP/1.1
Host: www.iana.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive

HTTP/1.0 200 OK
Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 9858
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive

....

Опубликовано: 06 мая 2021

Вернуться в блог

Что отличает настоящего айтишника?

Настоящий знает, как работает Интернет. Рассказываем для всех простым языком, как работает HTTP.

Видео

HTTP

Структура HTTP-запросов и ответов

В HTTP и запрос, и ответ имеют похожую структуру:

1. URL
2. Метод
3. Версия HTTP
4. Заголовки
5. Статус-код (обязательно только для HTTP-ответов)
6. Тело (необязательно)

Пример HTTP-запроса:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

, где

• POST — метод,
• /cgi-bin/process.cgi — URL,
• HTTP/1.1 — версия протокола HTTP,
• User-Agent, Host и другие — заголовки
• licenseID=string&content=string&/paramsXML=string — тело запроса.

Пример HTTP-ответа:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

В данном ответе отсутствует URL и метод, зато появился статус-код 200, означающий «успех».

URL запроса

Структура URL-адреса

http://blog.example.com:80/catalog/category/knifes?key1=value1&key2=value2#anchor

где

• http:// — протокол
• blog — поддомен (субдомен, домен третьего уровня)
• example — домен (домен второго уровня)
• com — доменная зона (домен первого уровня)
• 80 — порт. Для http — 80, для https — 443
• /catalog/category/knifes — ЧПУ-адрес (человеко-понятный URL)
• key1=value1&key2=value2 — GET параметры запроса
• anchor — якорь

Абсолютные и относительные URL

Абсолютные адреса в проекте — зло. Используйте относительные.

Абсолютный URL

https://developer.mozilla.org/ru/docs/Learn

Абсолютный URL, скрыт протокол

//developer.mozilla.org/ru/docs/Learn

Относительный URL (неправильно) 🚫

ru/docs/Learn

если мы на странице https://domain.ru/ru/about, то преобразуется в https://domain.ru/ru/aboutru/docs/Learn

Относительный URL (правильно) ✅

/ru/docs/Learn

если мы на странице https://domain.ru/ru/about, то преобразуется в https://domain.ru/ru/docs/Learn

Якоря (анкоры) ⚓️

Якоря придуманы в HTML, чтобы давать ссылки не просто на HTML-страницу, а на определенное место на странице. Позже якоря стали активно использоваться для передачи параметров в JS.

URL с якорем

https://domain.ru/url#someAnchor

HTML-элемент, на который ведет якорь

<h2 name="someAnchor">Заголовок с якорем</h2>

Методы HTTP-запросов

Если при повторении одного и того же запроса на сервере ничего не меняется, запрос считается идемпотентным. Если повторение одинакового запроса несколько раз изменяет состояние сервера, то он не идемпотентен и, вообще говоря, менее безопасен.

PUT заменяет существующую сущность. Те элементы сущности, которые не представлены в запросе, будут очищены или заменены на null.

GET и POST параметры

В контексте методов HTTP-запросов стоит упомянуть GET и POST параметры, так как вы будете постоянно с ними встречаться и так проще понять, как используются методы.

GET-параметры передаются в URL запроса. Пример URL с GET-параметрами я приводил выше. Любой из перечисленных ниже методов может иметь или не иметь GET-параметры, это совершенно нормально.

POST-параметры — это любые параметры, передаваемые в теле (body) запроса. POST-параметры не следует использовать для некоторых методов, например, для GET, DELETE и HEAD.

Статус-коды ответа

По группам

• 100 — 199 Информационные
• 200 — 299 Успешные
• 300 — 399 Редиректы
• 400 — 499 Клиентские ошибки
• 500 — 599 Серверные ошибки

Популярные коды ответа

• Для редиректов SEO-шники рекомендуют 301 редиректы.
• 401 не авторизован (юзер не представился)
• 403 запрещено (юзер не уполномочен)
• 404 ресурс не найден
• 418 я чайник
• 419 кука протухла (обычно ошибка проверки CSRF)
• 502 Bad Gateway. Программа веб-сервер (Nginx) получила неправильный ответ от бэкенда (PHP). Скорее всего, что-то сломалось или неправильно настроено на сервере
• 504 Gateway Timeout. Программа веб-сервер устала ждать ответа от бэкенда и отменила запрос к нему. Скорее всего, на бэкенде происходит что-то очень долгое, какое-то большое вычисление. Ну и все равно это не нормально, такого быть не должно.
• 503 Maintenance Mode. На сервере ведутся технические работы.

Коды ответа, как и заголовки, можно посмотреть в браузере на вкладке Network или получить командой curl -I domain.ru. В отличие от заголовков, коды ответа бывают только в ответе и не используются в запросе.

Заголовки HTTP

Заголовки — часть HTTP-запроса и/или HTTP-ответа, они не видимы пользователю. Представляют собой пары ключ: значение. Заголовки можно посмотреть в браузере на вкладке Network или получить командой curl -I domain.ru (так можно получить только заголовки ответа сервера).

Заголовки запроса

• Host — ВАЖНО. Домен, по которому мы переходим
• Cookie — куки, отдаваемые браузером серверу
• User-Agent — браузер, которым делаем запрос
• Accept-Language и Accept-Encoding — принимаемые браузером язык и кодировка
• Referer — предыдущая страница
• Authorization — реквизиты для базовой авторизации (логин, пароль)

Заголовки ответа

• Cache-Control — сервер говорит браузеру, как кэшировать данные
• Content-Type — тип и подтип содержимого, а также кодировка и приложение для открытия содержимого. Примеры:
  • Content-Type: text/html; charset=UTF-8 — Тип текст, подтип HTML. Кодировка UTF-8
  • Content-Type: image/gif — Тип картинка, подтип GIF
  • Content-Type: application/pdf — Тип «открываемый внешним приложением», подтип PDF
• Content-Disposition — говорит браузеру, скачивать или открывать документ как веб-страницу
• Location — заголовок для редиректа
• Set-Cookie — сервер передает браузеру куку
• WWW-Authenticate — выводит окно с базовой аутентификацией
• Content-Encoding — сервер говорит браузеру, сжата ли страница и в каком виде
• Server и X-Powered-By — технологии, на которых работает сайт

HTTP-редиректы

Редиректы — способ перенаправить браузер на другой URL. Это похоже на то, как если бы вы пришли в магазин и там увидели надпись «мы переехали, вот наш новый адрес». После этого вы идете в магазин по новому адресу. Важно понимать, что редирект со стороны сайта лишь просит ваш браузер перейти на другой адрес, а не подсовывает вам другую страницу. Другими словами, технически редирект происходит на стороне клиента, а не сервера.

www и http://

Проверка редиректов очень важна для проверки настроек префиксов домена типа www и http/https.

То есть у каждого домена обычно есть 4 варианта написания:

И 3 из этих 4 вариантов обязательно должны ссылаться на один из них, то есть на главный. Главный вариант определяет заказчик, но обычно это https://domain.ru

Инструменты

Редиректы можно проверить браузером через вкладку Network

Разработчикам будет удобнее воспользоваться утилитой

	curl -I -L https://domain.ru

Как сбросить кэш редиректов браузера

На Windows нажать ctrl+H, затем «очистить историю», оставить включенной (отжатой) только галочку напротив «Изображения и другие файлы, сохраненные в кэше». Затем нажать «удалить данные».

SSL шифрование

Принцип — передача только зашифрованных данных.

Типы SSL-сертификатов

• Платные (Comodo, Thawte, reg.ru)
  • Срок — 1 год или более
  • Стоимость — от 1500 руб/год
• Let’s Encrypt (обычно мы используем именно LE)
  • Срок — 3 месяца
  • Стоимость — бесплатно
  • Нюанс: Wild Card сертификаты для поддоменов (*.flagsoft.ru). Доступны в LE только при DNS-аутентификации, то есть добавлении TXT-записи, которую нужно обновлять каждые 3 месяца. Для обновления используется API, которое есть не у всех DNS-провайдеров.

Диагностика SSL

Если на сайте проблемы с SSL, то причина — в одном из двух:

• Что-то не так с сертификатом (кончился, выдан не на этот домен или самоподписанный)
• Страница запрашивает что-то по HTTP

На скриншоте видно, как посмотреть подробности о сертификате и наличие ошибок в странице. Конкретно на этом скриншоте показана вторая проблема, так называемая «mixed-content error», то есть часть контента прилетает по HTTP.

Для диагности SSL на вашем сайте вы также можете использовать онлайн-сервис  https://www.ssllabs.com/ssltest/ .
Учтите, данные о сертификате, как и HTTP-редиректы, сильно кэшируются браузером. Сбрасываются так же, как кэш редиректов (смотрите выше).

Версии HTTP

HTTP/2

Суть — мультиплексирование запросов по TCP.

Преимущества перед HTTP/1.1

• Скорость. HTTP/2 — бинарный протокол, а HTTP/1.1 — текстовый
• Скорость. Мультиплексирование множества запросов в одном соединении TCP
• Скорость. Сжатие HTTP-заголовков
• Server Push. Принудительная отправка данных сервером в браузер
• Приоритеты запросов

Минусы

• Из-за «head-of-line blocking» на медленном интернете HTTP/1.1 работает быстрее
• Для работы HTTP/2 нужен SSL

Распространение: По данным W3Techs на 1 ноября 2020 года, 49% из 10 млн самых популярных интернет-сайтов поддерживают протокол HTTP/2.

Подробная статья с понятными картинками — https://habr.com/ru/company/nix/blog/304518/

HTTP/3

Суть — мультиплексирование по UDP.

Преимущества перед HTTP/2:

• Решена проблема «head-of-line blocking»
• Шифрование и транспорт объединены, пакеты шифруются независимо
• Протокол реализуется на уровне приложений, а не ОС. Поэтому быстро внедряется

Минусы:

• Протокол реализуется на уровне приложений, а не ОС. Поэтому HTTP/3 использует больше CPU

Результаты: По данным Google, страницы загружаются примерно на 5% быстрее, а в потоковом видео на 30% меньше подвисаний по сравнению с TCP.

Распространение: По данным W3Techs на 1 сентября 2020 года, 7% из 10 млн самых популярных интернет-сайтов поддерживают протокол HTTP/3.

Если у вас появились какие-то вопросы, вы можете задать их в комментариях, а мы на них ответим 🙂