# Протокол HTTP

### Содержание

* [Методы HTTP - запросов](#metody-http-zaprosov)
* [Различия GET, POST, PUT](#razlichiya-metodov-get-i-post)
* [Структура HTTP - сообщения](#struktura-http-soobsheniya)
* [Заголовки HTTP](#zagolovki-http)
* [Коды состояний](#kodi-sostoyanii)

**HTTP (HyperText Transfer Protocol)** – это протокол, который используется для передачи данных между веб-серверами и веб-браузерами. Он обеспечивает способ общения и передачи информации в Интернете.

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

Каждый метод имеет свой смысл, но есть и общие характеристики, как, например, безопасность (информация не меняется), идемпотентность (повторные запросы не меняют результат) или возможность кэширования.

**HTTPS (аббр. от англ. HyperText Transfer Protocol Secure)** - расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL.

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения - от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства и сертификат сервера проверен и ему доверяют.

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

Существуют следующие методы HTTP-запросов:

* [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET)

  [<br>](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET)Метод GET используется для получения информации или данных о конкретном ресурсе на сервере.
* [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD)\
  Метод HEAD запрашивает ответ, идентичный запросу GET, но без тела ответа. То есть, при использовании метода HEAD сервер отправляет только заголовки ответа, содержащие метаинформацию о ресурсе, а само содержимое (текст, изображение и т. д.) не включается в ответ.
* [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST)\
  Метод POST используется, чтобы отправить данные на сервер для выполнения каких-либо действий, например, создания новой записи в базе данных, обновления информации.
* [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT)\
  Метод PUT в HTTP используется, чтобы полностью заменить все текущие данные целевого ресурса (например, файл или запись в базе данных) на те данные, которые были отправлены в запросе. Если вы используете метод PUT для какого-либо ресурса, то вы переписываете всю существующую информацию на новую.
* [DELETE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE)\
  Метод DELETE удаляет указанный ресурс.
* [CONNECT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT)\
  Метод CONNECT устанавливает “туннель” между клиентом и сервером. Это часто используется для установления защищенных соединений, например, при работе через прокси-сервер. Такой туннель позволяет клиенту и серверу обмениваться данными в безопасной среде, обеспечивая конфиденциальность и безопасность информации.
* [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS)\
  Когда клиент отправляет запрос методом OPTIONS, сервер отвечает, предоставляя информацию о том, какие методы запросов, заголовки и другие параметры могут быть использованы для взаимодействия с этим ресурсом.
* [TRACE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/TRACE)\
  При отправке запроса методом TRACE сервер принимает этот запрос, а затем возвращает его обратно клиенту в виде ответа. Это позволяет клиенту увидеть, через какие промежуточные серверы и прокси-серверы прошел запрос на пути к целевому ресурсу.
* [PATCH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PATCH)\
  Метод PATCH в HTTP используется для внесения частичных изменений в ресурс. Вместо того чтобы заменять весь ресурс новыми данными, как это делает метод PUT, метод PATCH позволяет отправлять только те части ресурса, которые требуют изменения.

#### **Различия методов GET и POST**

Основное состоит в способе передачи данных веб-формы обрабатывающему скрипту, а именно:

* Метод GET отправляет скрипту всю собранную информацию формы как часть URL: <http://www.komtet.ru/script.php?login=admin\\&name=komtet>
* Метод POST передает данные таким образом, что пользователь сайта уже не видит передаваемые скрипту данные: <http://www.komtet.ru/script.php>

Кроме того:

* Количество информации, передаваемой методом GET через URL строку ограничено 2048 символами (минус служебная информация браузера);
* Страницу, сгенерированную методом GET, можно добавить в закладки и поделиться ссылкой;
* Метод POST в отличие от метода GET позволяет передавать запросу файлы;
* При использовании метода GET существует риск того, что поисковый робот может выполнить тот или иной открытый запрос.

**Когда использовать GET и POST?** Используйте метод GET, когда необходимо просто запросить данные с сервера без изменения состояния сервера. Используйте метод POST, когда необходимо отправить данные на сервер для обработки и/или изменения состояния сервера.

#### В чем различие PUT и POST методов?

Разница между PUT и POST в том, что PUT является идемпотентным, т. е. единичный и множественные вызовы этого метода, с идентичным набором данных, будут иметь тот же результат выполнения (без сторонних эффектов), в случае с POST , множественный вызов с идентичным набором данных может повлечь за собой сторонние эффекты.

Говоря проще, POST всегда создаёт новую запись, PUT - создает и обновляет

### **Структура HTTP-сообщения**

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

1. **Стартовая строка** (англ. Starting line) - определяет тип сообщения, различается для запроса и ответа;
2. **Заголовки** (англ. Headers) - характеризуют тело сообщения, параметры передачи и прочие сведения;
3. **Тело сообщения** (англ. Message Body) - непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.

**1. Стартовая строка**:

* Стартовая строка запроса выглядит так: *Метод URI HTTP/Версия*, где:

  * Метод (англ. Method) - тип запроса, одно слово заглавными буквами;
  * URI определяет путь к запрашиваемому документу;
  * Версия (англ. Version) - пара разделенных точкой цифр. Например: 1.1.

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

  GET /wiki/HTTP HTTP/1.1

  Host: ru.wikipedia.org
* Стартовая строка ответа сервера имеет следующий формат: *HTTP/Версия КодСостояния Пояснение*, где:

  * Версия - пара разделенных точкой цифр, как в запросе;
  * Код состояния (англ. Status Code) - три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента;
  * Пояснение (англ. Reason Phrase) - текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

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

  HTTP/1.0 200 OK

**2. Заголовки:** Заголовки HTTP (англ. HTTP Headers) - это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой. Примеры заголовков:

* Server: Apache/2.2.11 (Win32) PHP/5.3.0
* Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
* Content-Type: text/plain; charset=windows-1251
* Content-Language: ru

В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до двоеточия, называется именем (англ. name), а что после него - значением (англ. value).

Все заголовки разделяются на четыре основных группы:

* General Headers («Основные заголовки») - могут включаться в любое сообщение клиента и сервера;
* Request Headers («Заголовки запроса») - используются только в запросах клиента;
* Response Headers («Заголовки ответа») - только для ответов от сервера;
* Entity Headers («Заголовки сущности») - сопровождают каждую сущность сообщения.

Именно в таком порядке рекомендуется посылать заголовки получателю.

Все необходимые для функционирования HTTP заголовки описаны в основных RFC. Если не хватает существующих, то можно вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией Microsoft для расширения WebDAV. Больше можно узнать [тут](https://developer.mozilla.org/ru/docs/Web/HTTP/Headers).

*Какие заголовки важны тестировщику: очевидно, смотря что мы тестируем. В основном это заголовки, касающиеся авторизации, кук, кэша и юзер-агент, хотя для того же security тестера они будут иные. Больше* [*тут*](https://habr.com/ru/post/413205/) *и* [*тут*](https://xakep.ru/2011/05/24/55557/)*.*

*Как сервер узнает, с какого типа устройства/браузера/ОС/языка вы открываете веб-сайт (Например, для Adaptive design): когда вы отправляете HTTP-запрос, он содержит в себе заголовки (headers) с различной информацией. Одним из них является User-Agent. Он сообщает: браузер, его версию и язык, движок браузера, версию движка, операционную систему.*

**3. Тело сообщения**: Тело HTTP-сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.

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

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

Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения может быть добавлено в запрос, только когда метод запроса допускает тело объекта.

Включается или не включается тело сообщения в сообщение ответа - зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения, даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения. Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.

### Заголовки HTTP <a href="#zagolovki-http" id="zagolovki-http"></a>

После стартовой строки в HTTP-запросе передаются заголовки (HTTP Headers) — строки, содержащие пару ключ-значение, разделённую двоеточием. Ключ, или название заголовка, не чувствителен к регистру, но по историческим причинам обычно каждое слово в составе ключа пишется с заглавной буквы.

Заголовки HTTP-запросов можно разделить на основные (General Headers), заголовки запроса (Request Headers) и сущности (Entity Headers). Основные и заголовки сущности применяются и к запросам клиента, и к ответам сервера, а заголовки запроса, как следует из названия, — только к запросам. Заголовки сущности необязательны и могут передаваться в том случае, если у запроса есть какое-либо тело (body), например при использовании метода POST.

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

Вот список самых распространённых заголовков, включаемых в HTTP-запросы:

* Host. Содержит имя домена или IP-адрес, к которому выполняется запрос. Также может включать необязательный номер порта, отделённый от адреса двоеточием.
* Connection. Позволяет удерживать соединение открытым после завершения запроса (keep-alive) для экономии сетевых ресурсов.
* Accept. Указывает, какие типы содержимого (Multipurpose Internet Mail Extensions, MIME) может понять клиент.
* Accept-Encoding. Обычно определяет алгоритм сжатия контента.
* Accept-Language. Указывает предпочитаемый язык клиента.
* Cache-Control. Инструкции по кешированию запросов и ответов.
* Refer. Предоставляет исходный адрес, с которого пользователь перешёл на текущую страницу.
* Cookie. Содержит сохранённые на стороне клиента фрагменты данных, обычно используемые для сохранения состояния соединения. Cookie могут устанавливаться как сервером, так и клиентом.
* Authorization. Используется для проверки подлинности пользователя. Токен авторизации, передаваемый в этом поле, не требует хранения данных на стороне сервера. Этот метод является альтернативой аутентификации с помощью cookie и имеет как преимущества, так и недостатки. Может быть полезен в сетевых сервисах или распределённых системах.
* User-Agent. Характеристики клиента, по которым сервер может определить производителя и версию браузера, тип приложения и операционную систему пользователя.

С полным списком заголовков можно ознакомиться, например, в [Википедии](https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%B7%D0%B0%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BA%D0%BE%D0%B2_HTTP) или [MDN](https://developer.mozilla.org/ru/docs/Web/HTTP/Headers).

### Коды состояний <a href="#kodi-sostoyanii" id="kodi-sostoyanii"></a>

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

* информационные коды, 100...199;
* успешные коды, 200...299;
* коды перенаправления, 300...399;
* коды клиентских ошибок, 400...499;
* коды серверных ошибок, 500...599.

Вот список некоторых кодов состояния, чаще всего встречающихся в HTTP-ответах:

**Информационные**

* 100 Continue (Продолжить). Промежуточный ответ, который говорит о том, что запрос успешно принят.
* 102 Processing (В обработке). Указывает, что обработка запроса ещё не завершена.

**Успешные**

* 200 OK (Успешно). Пояснение говорит само за себя. Запрос успешно выполнен в соответствии с переданным методом.
* 201 Created (Создано). В результате выполнения запроса PUT был создан ресурс.
* 206 Partial Content (Частичное содержимое). Используется для загрузки контента в несколько потоков.

**Сообщения о перенаправлениях**

* 301 Moved Permanently (Перемещён на постоянной основе). Означает, что URL запрашиваемого ресурса был изменён.
* 302 Found (Найдено). Указывает, что запрошенный ресурс временно изменён. Например, после успешной авторизации клиент может быть перенаправлен на страницу своего профиля.
* 304 Not Modified (Не модифицировано). Используется для кеширования. Если запрошенный ресурс не был изменён, клиент может продолжать использовать сохранённую версию ответа.

**Клиентские**

* 400 Bad Request (Недействительный запрос). Означает, что сервер не может корректно обработать полученные данные.
* 401 Unauthorized (Неавторизованно). Для получения ответа на этот запрос нужна авторизация.
* 403 Forbidden (Запрещено). У клиента нет прав доступа к запрашиваемой странице. В отличие от 401, дальнейшая аутентификация невозможна.
* 404 Not Found (Не найдено). Сервер не смог найти запрашиваемую страницу. Пожалуй, это самый известный в интернете код ответа.
* 405 Method Not Allowed (Метод не разрешён). Вызов этого метода запрещён на стороне сервера. Обязательные методы GET и HEAD не могут быть запрещены.

**Серверные**

* 500 Internal Server Error (Внутренняя ошибка). В процессе обработки запроса сервер столкнулся с ошибкой, которую не смог обработать.
* 501 Not Implemented (Не реализовано). Сервер не поддерживает запрашиваемый метод. Методы GET и HEAD являются обязательными и не должны возвращать этот код.
* 502 Bad Gateway (Плохой шлюз). Эта ошибка обычно означает, что в процессе обработки запроса сервер выполнил обращение к внутренней службе, но получил недействительный ответ.
* 503 Service Unavailable (Сервис недоступен). Зачастую причиной этой ошибки бывает отключение или перегрузка сервера.
* 504 Gateway Timeout (тайм-аут шлюза). Этот ответ об ошибке возвращается, когда сервер не может получить ответ от внутренней службы вовремя.

Полный список кодов состояния можно найти, например, в [Википедии](https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F_HTTP) или [MDN](https://developer.mozilla.org/ru/docs/Web/HTTP/Status).

**Почему ошибка 404 относится к 4** - клиентской, если по интуитивно должна быть серверной? Объясняется это тем, что сервер работает и готов вернуть страницу в ответ на запрос, однако страницы по запрашиваемому адресу у него попросту нет. Таким образом, вины сервера в этом нет и предполагается опечатка в URL, которая является виной клиента. В этом вопросе сбивает с толку то, что ошибка 404 часто возвращается, когда страница была перемещена или удалена, или не совпадает имя файла в коде и на сервере. Тогда корректнее показывать ошибки 301 Moved Permanently (перемещено), что можно настроить в конфигурации большинства серверов, либо производить перенаправление на другой URL, и возвращать код 410 Gone (удалено). Однако, так как эти два варианта требуют специальной настройки сервера, большинство веб-сайтов не используют их.

**На какой метод не может вернуться ошибка 501?** The HTTP 501 Not Implemented серверный код ответа на ошибку указывает, что метод запроса не поддерживается сервером и не может быть обработан. Единственными методами, которые необходимы серверам для поддержки (и, следовательно, не должны возвращать этот код), являются GET и HEAD.

Дополнительные материалы:

[HTTP-запросы: структура, методы, заголовки, строка статуса и коды состояния](https://firstvds.ru/technology/metody-http-zaprosa)

[HTTP протокол - лекция Ивана Бибилова](https://youtu.be/yUHlrabtEaU)

[Методы GET и POST. Использование и отличия](https://guruweba.com/html/metody-get-i-post-ispolzovanie-i-otlichiya/)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://qabook.gitbook.io/start/teoriya-testirovaniya/seti-i-arkhitektura/protokol-http.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.