Как выглядит http get запрос

Ультимативный гайд по HTTP. Структура запроса и ответа

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

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

Что такое HTTP

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

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

Как правило, передача данных по HTTP осуществляется через открытое TCP/IP-соединение 1 . Серверное программное обеспечение по умолчанию обычно использует 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 — это текстовый протокол, поэтому и все данные передаются в виде текста. Заголовки можно отделить друг от друга только переносом строки. Нельзя использовать запятые, точку с запятой, или другие разделители. Всё, что идет после имени заголовка с двоеточием и до переноса строки, будет считаться значением заголовка 2 .

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

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. 3

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

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

POST /path HTTP/1.1 Host: localhost Первая строка Вторая строка после разрыва

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

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

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. 5 При использовании этого механизма знак «=» будет преобразован в код %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

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

Сообщения HTTP состоят из текстовой информации в кодировке ASCII, записанной в несколько строк. В HTTP/1.1 и более ранних версиях они пересылались в качестве обычного текста. В HTTP/2 текстовое сообщение разделяется на фреймы, что позволяет выполнить оптимизацию и повысить производительность.

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

Механизм бинарного фрагментирования в HTTP/2 разработан так, чтобы не потребовалось вносить изменения в имеющиеся APIs и конфигурационные файлы: он вполне прозрачен для пользователя.

HTTP запросы и ответы имеют близкую структуру. Они состоят из:

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

Стартовую строку вместе с заголовками сообщения HTTP называют головой запроса, а его данные — телом.

Запросы HTTP

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

HTTP запросы — это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера. Их стартовая строка состоит из трёх элементов:

1. Метод HTTP, глагол (например, GET , PUT или POST ) или существительное (например, HEAD или OPTIONS ), описывающие требуемое действие. Например, GET указывает, что нужно доставить некоторый ресурс, а POST означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа).
2. Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Формат цели запроса зависит от используемого HTTP-метода. Это может быть
   • Абсолютный путь, за которым следует ‘?’ и строка запроса. Это самая распространённая форма, называемая исходной формой (origin form) . Используется с методами GET , POST , HEAD , и OPTIONS . POST / HTTP 1.1 GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0
   • Полный URL — абсолютная форма (absolute form) , обычно используется с GET при подключении к прокси. GET http://developer.mozilla.org/ru/docs/Web/HTTP/Messages HTTP/1.1
   • Компонента URL «authority», состоящая из имени домена и (необязательно) порта (предваряемого символом ‘:’ ), называется authority form. Используется только с методом CONNECT при установке туннеля HTTP. CONNECT developer.mozilla.org:80 HTTP/1.1
   • Форма звёздочки (asterisk form), просто «звёздочка» ( ‘*’ ) используется с методом OPTIONS и представляет сервер. OPTIONS * HTTP/1.1
3. Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа.

Заголовки

Заголовки запроса HTTP имеют стандартную для заголовка HTTP структуру: не зависящая от регистра строка, завершаемая ( ‘:’ ) и значение, структура которого определяется заголовком. Весь заголовок, включая значение, представляет собой одну строку, которая может быть довольно длинной.

Существует множество заголовков запроса. Их можно разделить на несколько групп:

• Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом
• Заголовки запроса (Request headers), например, User-Agent , Accept-Type , уточняющие запрос (как, например, Accept-Language ), придающие контекст (как Referer ), или накладывающие ограничения на условия (like If-None ).
• Заголовки сущности, например Content-Length , относящиеся к телу сообщения. Как легко понять, они отсутствуют, если у запроса нет тела.

Тело

Последней частью запроса является его тело. Оно бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как GET , HEAD , DELETE , или OPTIONS , в нем обычно не нуждаются. Но некоторые запросы отправляют на сервер данные для обновления, как это часто бывает с запросами POST (содержащими данные HTML-форм).

Тела можно грубо разделить на две категории:

• Одноресурсные тела (Single-resource bodies), состоящие из одного отдельного файла, определяемого двумя заголовками: Content-Type и Content-Length .
• Многоресурсные тела (Multiple-resource bodies), состоящие из множества частей, каждая из которых содержит свой бит информации. Они обычно связаны с HTML-формами.

Ответы HTTP

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

Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:

1. Версию протокола, обычно HTTP/1.1 .
2. Код состояния (status code), показывающая, был ли запрос успешным. Примеры: 200 , 404 или 302
3. Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP..

Пример строки статуса: HTTP/1.1 404 Not Found.

Заголовки

Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием ( ‘:’ ) и значение, структура которого определяется типом заголовка. Весь заголовок, включая значение, представляет собой одну строку.

Существует множество заголовков ответов. Их можно разделить на несколько групп:

• Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом.
• Заголовки ответа (Response headers), например, Vary и Accept-Ranges , сообщающие дополнительную информацию о сервере, которая не уместилась в строку состояния.
• Заголовки сущности (Entity headers), например, Content-Length , относящиеся к телу ответа. Отсутствуют, если у ответа нет тела.

Тело

Последней частью ответа является его тело. Оно есть не у всех ответов: у ответов с кодом состояния, например, 201 или 204 , оно обычно отсутствует.

Тела можно разделить на три категории:

• Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла известной длины, определяемые двумя заголовками: Content-Type и Content-Length .
• Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла неизвестной длины, разбитого на небольшие части (chunks) с заголовком Transfer-Encoding (en-US), значением которого является chunked .
• Многоресурсные тела (Multiple-resource bodies), состоящие из многокомпонентного тела, каждая часть которого содержит свой сегмент информации. Они относительно редки.

Фреймы HTTP/2

Сообщения HTTP/1.x имеют несколько недостатков в отношении производительности:

• Заголовки, в отличие от тел, не сжимаются.
• Заголовки, которые зачастую практически совпадают у идущих подряд сообщений, приходится передавать по отдельности.
• Мультиплексность невозможна. Приходится открывать соединение для каждого сообщения, а тёплые (warm) соединения TCP эффективнее холодных (cold).

HTTP/2 переходит на новый уровень: он делит сообщения HTTP/1.x на фреймы, которые внедряются в поток. Фреймы данных из заголовков отделены друг от друга, что позволяет сжимать заголовки. Несколько потоков можно объединять друг с другом — такой процесс называется мультиплексированием — что позволяет более эффективно использовать TCP-соединения.

Фреймы HTTP сейчас прозрачны для веб-разработчиков. Это дополнительный шаг, который HTTP/2 делает по отношению к сообщениям HTTP/1.1 и лежащему в основе транспортному протоколу. Для реализации фреймов HTTP веб-разработчикам не требуется вносить изменения в имеющиеся APIs; если HTTP/2 доступен и на сервере, и на клиенте, он включается и используется.

Заключение

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

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

This page was last modified on 7 авг. 2023 г. by MDN contributors.

HTTP-запрос методом GET.

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

Самый простой способ, как можно создать запрос методом GET- это набрать URL-адрес в адресную строку браузера.

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

Браузер передаст серверу примерно следующую информацию:

GET / HTTP/1.1 Host: site.ru User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0 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 Cookie: wp-settings Connection: keep-alive

Запрос состоит из двух частей:

1. строка запроса (Request Line)

2. заголовки (Message Headers)

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

Чтобы добавить GET параметры к запросу, нужно в конце URL-адреса поставить знак «?» и после него начинать задавать их по следующему правилу:

имя_параметра1=значение_параметра1& имя_параметра2=значение_параметра2&… 
Разделителем между параметрами служит знак «&».

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

http://site.ru/page.php?name=dima&age=27

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

Вот пример, как это можно сделать на языке PHP.

"; echo "Ваш возраст: " . $_GET["age"] . "
"; ?>

Конструкция $_GET[«имя_параметра»] позволяет выводить значение переданного параметра.

В результате выполнения этого кода в браузере выведется:

Ваше имя: dima Ваш возраст: 27

Кстати, переходя по какой-либо ссылке, которая оформлена в HTML вот так:

мы тоже выполняем запрос к серверу методом GET.

Все мои уроки по серверному программированию здесь.

Чтобы оставить сообщение, зарегистрируйтесь/войдите на сайт через:

HTTP-запросы — что это

Протокол связи HTTP — HyperText Transfer Protocol был разработан специально для передачи данных и просмотра интернет-страниц. Каждое взаимодействие по HTTP выглядит как общение между пользователем и сервером: человек с помощью клиента делает запрос (HTTP Requests) к серверу, а сервер даёт ответ — допустим, отображает сайт в браузере.

Фактически запросы представляют собой некие информационные сообщения, которые клиент передаёт на сервер с целью выполнения какого-либо действия. У каждого HTTP Requests должен быть задан URL-адрес и метод, а основой выступает хедер (HTTP-заголовок).

HTTP-запросы наполнены несколькими текстовыми строками, которые закодированы в ASCII. Версии HTTP/1.1 и ранее предполагали использование данных в виде обычного текста. В более совершенной версии HTTP/2 текстовую информацию стали разделять на фреймы.

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

HTTP-запросы могут выглядеть следующим образом: GET https://www.cloud4y.ru/ HTTP/1.1

Здесь вы можете видеть, что в качестве метода используется GET, обращение идёт к ресурсу https://www.cloud4y.ru, а в качестве протокола используется версия HTTP/1.1.

Для большей наглядности изобразим это так:

Традиционно запросы обладают структурой следующего вида:

1. Стартовая строка. Необходима для описания запроса или статуса. В ней сообщается версия протокола и другие сведения. Это может быть запрашиваемый ресурс или код ответа (например, ошибки). Длина — ровно одна строчка.
2. HTTP-заголовок. Выглядит как несколько строчек текста, в которых уточняется запрос или описывается содержимое тела сообщения.
3. Пустая строка. Она необходима, чтобы сообщить об успешной отправке метаданных конкретного запроса.
4. Тело запроса. В нём хранится информация о запросе или документ, который отправляется в ответе на запрос.

А теперь чуть более детально.

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

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

Метод — короткое слово, которое указывает, что требуется сделать с запрашиваемым ресурсом. Чаще всего встречаются методы глагольной формы (GET, PUT или POST) или существительные (HEAD, OPTIONS). GET, например, даёт серверу понять, что пользователю требуются некие данные, а POST означает, что пользователь отправляет данные на сервер.

Цель запроса фактически является указателем нужного пользователю URL. Состоит из протокола, URL или IP-адреса, пути к хранящемуся на сервере ресурсу. Также в состав цели запроса могут входить указание порта, параметры запроса.

Версия используемого протокола передачи данных. Сейчас распространены версии HTTP/1.1 и HTTP/2. От протокола зависит структура данных, идущих вслед за стартовой строкой.

Отметим, что в стартовой строке могут храниться и другие полезные сведения. Например, User-Agent header — данные об используемом юзер-агенте, то есть браузере. Или Referer header — здесь подразумевается URL, с которого поступил запрос.

Аренда облачного сервера для разработки, хостинга, обученияПодробнее

HTTP-заголовок

Заголовки выглядят как пара _имя:значение_. Строка не зависит от регистра, а структура значения определяется заголовком. Хедер выглядит как одна, порой чрезвычайно длинная строка. Заголовки используются для передачи вместе с запросом дополнительных сведений и могут принадлежать к одной из четырёх категорий.

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

Пустая строка

На самом деле эта строка не пуста, она содержит параметр CTRLF, обозначающий конец заголовка.

Тело запроса

Тело HTTP-запроса может быть не у всех запросов. Например, для методов GET, HEAD, DELETE, OPTIONS тело, как правило, не нужно. А вот для методов типа POST оно необходимо — чтобы отправлять на сервер информацию для обновления, например.

Тело запроса условно делится на две категории, одноресурсное и многоресурсное. К первой категории относятся тела запроса, состоящие из одного обособленного файла с двумя заголовками: Content-Type и Content-Length.

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

Помимо HTTP-запросов существуют ещё и ответы. Но это уже совсем другая история.