Http решебник: Коды ответа HTTP — HTTP

Коды ответа HTTP — HTTP

Код ответа (состояния) HTTP показывает, был ли успешно выполнен определённый HTTP запрос. Коды сгруппированы в 5 классов:

Коды состояния определены в 10-ой секции RFC 2616. Обновленную спецификацию можно найти в RFC 7231 .

Если вы получили код ответа (состояния), которого нет в данном списке, в таком случае он является не стандартизированным кодом ответа (состояния), вероятней всего он кастомный сервера.

Код ответа	Название	Описание	Версия HTTP
Информационные
100	Continue	«Продолжить». Этот промежуточный ответ указывает, что запрос успешно принят и клиент может продолжать присылать запросы либо проигнорировать этот ответ, если запрос был завершён.	Только HTTP/1.1
101	Switching Protocol	«Переключение протокола». Этот код присылается в ответ на запрос клиента, содержащий заголовок Upgrade:, и указывает, что сервер переключился на протокол, который был указан в заголовке. Эта возможность позволяет перейти на несовместимую версию протокола и обычно не используется.	Только HTTP/1.1
102	Processing	«В обработке». Этот код указывает, что сервер получил запрос и обрабатывает его, но обработка ещё не завершена.	Только HTTP/1.1
103	Early Hints	«Ранние подсказки». В ответе сообщаются ресурсы, которые могут быть загружены заранее, пока сервер будет подготавливать основной ответ. RFC 8297 (Experimental).	Только HTTP/1.1
Успешные
200	OK	«Успешно». Запрос успешно обработан. Что значит «успешно», зависит от метода HTTP, который был запрошен: GET: «ПОЛУЧИТЬ». Запрошенный ресурс был найден и передан в теле ответа. HEAD: «ЗАГОЛОВОК». Заголовки переданы в ответе. POST: «ПОСЫЛКА». Ресурс, описывающий результат действия сервера на запрос, передан в теле ответа. TRACE: «ОТСЛЕЖИВАТЬ». Тело ответа содержит тело запроса полученного сервером.	HTTP/0.9 и выше
201	Created	«Создано». Запрос успешно выполнен и в результате был создан ресурс. Этот код обычно присылается в ответ на запрос PUT «ПОМЕСТИТЬ».	HTTP/0.9 и выше
202	Accepted	«Принято». Запрос принят, но ещё не обработан. Не поддерживаемо, т.е., нет способа с помощью HTTP отправить асинхронный ответ позже, который будет показывать итог обработки запроса. Это предназначено для случаев, когда запрос обрабатывается другим процессом или сервером, либо для пакетной обработки.	HTTP/0.9 и выше
203	Non-Authoritative Information	«Информация не авторитетна». Этот код ответа означает, что информация, которая возвращена, была предоставлена не от исходного сервера, а из какого-нибудь другого источника. Во всех остальных ситуациях более предпочтителен код ответа 200 OK.	HTTP/0.9 и 1.1
204	No Content	«Нет содержимого». Нет содержимого для ответа на запрос, но заголовки ответа, которые могут быть полезны, присылаются. Клиент может использовать их для обновления кешированных заголовков полученных ранее для этого ресурса.	HTTP/0.9 и выше
205	Reset Content	«Сбросить содержимое». Этот код присылается, когда запрос обработан, чтобы сообщить клиенту, что необходимо сбросить отображение документа, который прислал этот запрос.	Только HTTP/1.1
206	Partial Content	«Частичное содержимое». Этот код ответа используется, когда клиент присылает заголовок диапазона, чтобы выполнить загрузку отдельно, в несколько потоков.	Только HTTP/1.1
Сообщения о перенаправлениях
300	Multiple Choice	«Множественный выбор». Этот код ответа присылается, когда запрос имеет более чем один из возможных ответов. И User-agent или пользователь должен выбрать один из ответов. Не существует стандартизированного способа выбора одного из полученных ответов.	HTTP/1.0 и выше
301	Moved Permanently	«Перемещён на постоянной основе». Этот код ответа значит, что URI запрашиваемого ресурса был изменён. Возможно, новый URI будет предоставлен в ответе.	HTTP/0.9 и выше
302	Found	«Найдено». Этот код ответа значит, что запрошенный ресурс временно изменён. Новые изменения в URI могут быть доступны в будущем. Таким образом, этот URI, должен быть использован клиентом в будущих запросах.	HTTP/0.9 и выше
303	See Other	«Просмотр других ресурсов». Этот код ответа присылается, чтобы направлять клиента для получения запрашиваемого ресурса в другой URI с запросом GET.	HTTP/0. 9 и 1.1
304	Not Modified	«Не модифицировано». Используется для кеширования. Это код ответа значит, что запрошенный ресурс не был изменён. Таким образом, клиент может продолжать использовать кешированную версию ответа.	HTTP/0.9 и выше
305	Use Proxy	«Использовать прокси». Это означает, что запрошенный ресурс должен быть доступен через прокси. Этот код ответа в основном не поддерживается из соображений безопасности.	Только HTTP/1.1
306	Switch Proxy	Больше не использовать. Изначально подразумевалось, что » последующие запросы должны использовать указанный прокси.»	Только HTTP/1.1
307	Temporary Redirect	«Временное перенаправление». Сервер отправил этот ответ, чтобы клиент получил запрошенный ресурс на другой URL-адрес с тем же методом, который использовал предыдущий запрос. Данный код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.	Только HTTP/1.1
308	Permanent Redirect	«Перенаправление на постоянной основе». Это означает, что ресурс теперь постоянно находится в другом URI, указанном в заголовке Location: HTTP Response. Данный код ответа имеет ту же семантику, что и код ответа 301 Moved Permanently, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если POST использовался в первом запросе, POST должен использоваться и во втором запросе. Примечание: Это экспериментальный код ответа, Спецификация которого в настоящее время находится в черновом виде.	draft-reschke-http-status-308
Клиентские
400	Bad Request	«Плохой запрос». Этот ответ означает, что сервер не понимает запрос из-за неверного синтаксиса.	HTTP/0.9 и выше
401	Unauthorized	«Неавторизованно». Для получения запрашиваемого ответа нужна аутентификация. Статус похож на статус 403, но,в этом случае, аутентификация возможна.	HTTP/0.9 и выше
402	Payment Required	«Необходима оплата». Этот код ответа зарезервирован для будущего использования. Первоначальная цель для создания этого кода была в использовании его для цифровых платёжных систем(на данный момент не используется).	HTTP/0.9 и 1.1
403	Forbidden	«Запрещено». У клиента нет прав доступа к содержимому, поэтому сервер отказывается дать надлежащий ответ.	HTTP/0.9 и выше
404	Not Found	«Не найден». Сервер не может найти запрашиваемый ресурс. Код этого ответа, наверно, самый известный из-за частоты его появления в вебе.	HTTP/0.9 и выше
405	Method Not Allowed	«Метод не разрешён». Сервер знает о запрашиваемом методе, но он был деактивирован и не может быть использован. Два обязательных метода, GET и HEAD, никогда не должны быть деактивированы и не должны возвращать этот код ошибки.	Только HTTP/1.1
406	Not Acceptable	Этот ответ отсылается, когда веб сервер после выполнения server-driven content negotiation, не нашёл контента, отвечающего критериям, полученным из user agent.	Только HTTP/1.1
407	Proxy Authentication Required	Этот код ответа аналогичен коду 401, только аутентификация требуется для прокси сервера.	Только HTTP/1.1
408	Request Timeout	Ответ с таким кодом может прийти, даже без предшествующего запроса. Он означает, что сервер хотел бы отключить это неиспользуемое соединение. Этот метод используется все чаще с тех пор, как некоторые браузеры, вроде Chrome и IE9, стали использовать HTTP механизмы предварительного соединения для ускорения сёрфинга (смотрите баг 634278, будущей реализации этого механизма в Firefox). Также учитывайте, что некоторые серверы прерывают соединения не отправляя подобных сообщений.	Только HTTP/1.1
409	Conflict	Этот ответ отсылается, когда запрос конфликтует с текущим состоянием сервера.	Только HTTP/1.1
410	Gone	Этот ответ отсылается, когда запрашиваемый контент удалён с сервера.	Только HTTP/1.1
411	Length Required	Запрос отклонён, потому что сервер требует указание заголовка Content-Length, но он не указан.	Только HTTP/1.1
412	Precondition Failed	Клиент указал в своих заголовках условия, которые сервер не может выполнить	Только HTTP/1.1
413	Request Entity Too Large	Размер запроса превышает лимит, объявленный сервером. Сервер может закрыть соединение, вернув заголовок Retry-After	Только HTTP/1.1
414	Request-URI Too Long	URI запрашиваемый клиентом слишком длинный для того, чтобы сервер смог его обработать	Только HTTP/1. 1
415	Unsupported Media Type	Медиа формат запрашиваемых данных не поддерживается сервером, поэтому запрос отклонён	Только HTTP/1.1
416	Requested Range Not Satisfiable	Диапазон указанный заголовком запроса Range не может быть выполнен; возможно, он выходит за пределы переданного URI	Только HTTP/1.1
417	Expectation Failed	Этот код ответа означает, что ожидание, полученное из заголовка запроса Expect, не может быть выполнено сервером.	Только HTTP/1.1
Серверные
500	Internal Server Error	«Внутренняя ошибка сервера». Сервер столкнулся с ситуацией, которую он не знает как обработать.	HTTP/0. 9 и выше
501	Not Implemented	«Не реализовано». Метод запроса не поддерживается сервером и не может быть обработан. Единственные методы, которые сервера должны поддерживать (и, соответственно, не должны возвращать этот код) — GET и HEAD.	HTTP/0.9 и выше
502	Bad Gateway	«Плохой шлюз». Эта ошибка означает что сервер, во время работы в качестве шлюза для получения ответа, нужного для обработки запроса, получил недействительный (недопустимый) ответ.	HTTP/0.9 и выше
503	Service Unavailable	«Сервис недоступен». Сервер не готов обрабатывать запрос. Зачастую причинами являются отключение сервера или то, что он перегружен. Обратите внимание, что вместе с этим ответом удобная для пользователей(user-friendly) страница должна отправлять объяснение проблемы. Этот ответ должен использоваться для временных условий и Retry-After: HTTP-заголовок должен, если возможно, содержать предполагаемое время до восстановления сервиса. Веб-мастер также должен позаботиться о заголовках, связанных с кешем, которые отправляются вместе с этим ответом, так как эти ответы, связанные с временными условиями, обычно не должны кешироваться.	HTTP/0.9 и выше
504	Gateway Timeout	Этот ответ об ошибке предоставляется, когда сервер действует как шлюз и не может получить ответ вовремя.	Только HTTP/1.1
505	HTTP Version Not Supported	«HTTP-версия не поддерживается». HTTP-версия, используемая в запросе, не поддерживается сервером.	Только HTTP/1.1

запросы — структура (заголовок и тело), методы, строка статуса и коды состояния, ответы

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

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

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

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

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

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

Схема коммуникации устройств по HTTP-протоколу.

По умолчанию для коммуникации по 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.

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

Методы

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

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

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

Метод	Описание
GET	Позволяет запросить некоторый конкретный ресурс. Дополнительные данные могут быть переданы через строку запроса (Query String) в составе URL (например ?param=value).О составляющих URL мы поговорим чуть позже.
POST	Позволяет отправить данные на сервер. Поддерживает отправку различных типов файлов, среди которых текст, PDF-документы и другие типы данных в двоичном виде. Обычно метод POST используется при отправке информации (например, заполненной формы логина) и загрузке данных на веб-сайт, таких как изображения и документы.
HEAD	Здесь придется забежать немного вперед и сказать, что обычно сервер в ответ на запрос возвращает заголовок и тело, в котором содержится запрашиваемый ресурс. Данный метод при использовании его в запросе позволит получить только заголовки, которые сервер бы вернул при получении GET-запроса к тому же ресурсу. Запрос с использованием данного метода обычно производится для того, чтобы узнать размер запрашиваемого ресурса перед его загрузкой.
PUT	Используется для создания (размещения) новых ресурсов на сервере. Если на сервере данный метод разрешен без надлежащего контроля, то это может привести к серьезным проблемам безопасности.
DELETE	Позволяет удалить существующие ресурсы на сервере. Если использование данного метода настроено некорректно, то это может привести к атаке типа «Отказ в обслуживании» (Denial of Service, DoS) из-за удаления критически важных файлов сервера.
OPTIONS	Позволяет запросить информацию о сервере, в том числе информацию о допускаемых к использованию на сервере HTTP-методов.
PATCH	Позволяет внести частичные изменения в указанный ресурс по указанному расположению.

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. Заголовки представления, которые описывают формат данных сообщения и используемую кодировку. Добавляются к запросу только в тех случаях, когда с ним передается некоторое тело.

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

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

Заголовок	Описание
Host	Используется для указания того, с какого конкретно хоста запрашивается ресурс. В качестве возможных значений могут использоваться как доменные имена, так и IP-адреса. На одном HTTP-сервере может быть размещено несколько различных веб-сайтов. Для обращения к какому-то конкретному требуется данный заголовок.
User-Agent	Заголовок используется для описания клиента, который запрашивает ресурс. Он содержит достаточно много информации о пользовательском окружении. Например, может указать, какой браузер используется в качестве клиента, его версию, а также операционную систему, на которой этот клиент работает.
Refer	Используется для указания того, откуда поступил текущий запрос. Например, если вы решите перейти по какой-нибудь ссылке в этой статье, то вероятнее всего к запросу будет добавлен заголовок Refer: https://selectel.ru
Accept	Позволяет указать, какой тип медиафайлов принимает клиент. В данном заголовке могут быть указаны несколько типов, перечисленные через запятую (‘ , ‘). А для указания того, что клиент принимает любые типы, используется следующая последовательность — */*.
Cookie	Данный заголовок может содержать в себе одну или несколько пар «Куки-Значение» в формате cookie=value. Куки представляют собой небольшие фрагменты данных, которые хранятся как на стороне клиента, так и на сервере, и выступают в качестве идентификатора. Куки передаются вместе с запросом для поддержания доступа клиента к ресурсу. Помимо этого, куки могут использоваться и для других целей, таких как хранение пользовательских предпочтений на сайте и отслеживание клиентской сессии. Несколько кук в одном заголовке могут быть перечислены с помощью символа точка с запятой (‘ ; ‘), который  используется как разделитель.
Authorization	Используется в качестве еще одного метода идентификации клиента на сервере. После успешной идентификации сервер возвращает токен, уникальный для каждого конкретного клиента. В отличие от куки, данный токен хранится исключительно на стороне клиента и отправляется клиентом только по запросу сервера. Существует несколько типов аутентификации, конкретный метод определяется тем веб-сервером или веб-приложением, к которому клиент обращается за ресурсом.

Тело запроса

Завершающая часть 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-сервер может вернуть код, принадлежащий одной из пяти категорий кодов состояния:

Категория	Описание
1xx	Коды из данной категории носят исключительно информативный характер и никак не влияют на обработку запроса.
2xx	Коды состояния из этой категории возвращаются в случае успешной обработки клиентского запроса.
3xx	Эта категория содержит коды, которые возвращаются, если серверу нужно перенаправить клиента.
4xx	Коды данной категории означают, что на стороне клиента был отправлен некорректный запрос. Например, клиент в запросе указал не поддерживаемый метод или обратился к ресурсу, к которому у него нет доступа.
5xx	Ответ с кодами из этой категории приходит, если на стороне сервера возникла ошибка.

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

Категория	Описание
200 OK	Возвращается в случае успешной обработки запроса, при этом тело ответа обычно содержит запрошенный ресурс.
302 Found	Перенаправляет клиента на другой URL. Например, данный код может прийти, если клиент успешно прошел процедуру аутентификации и теперь может перейти на страницу своей учетной записи.
400 Bad Request	Данный код можно увидеть, если запрос был сформирован с ошибками. Например, в нем отсутствовали символы завершения строки.
403 Forbidden	Означает, что клиент не обладает достаточными правами доступа к запрошенному ресурсу. Также данный код можно встретить, если сервер обнаружил вредоносные данные, отправленные клиентом в запросе.
404 Not Found	Каждый из нас, так или иначе, сталкивался с этим кодом ошибки. Данный код можно увидеть, если запросить у сервера ресурс, которого не существует на сервере.
500 Internal Error	Данный код возвращается сервером, когда он не может по определенным причинам обработать запрос.

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

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

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

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

Категория	Пример	Описание
Server	Server: ngnix	Содержит информацию о сервере, который обработал запрос.
Set-Cookie	Set-Cookie:PHPSSID=bf42938f	Содержит куки, требуемые для идентификации клиента. Браузер парсит куки и сохраняет их в своем хранилище для дальнейших запросов.
WWW-Authenticate	WWW-Authenticate: BASIC realm=»localhost»	Уведомляет клиента о типе аутентификации, который необходим для доступа к запрашиваемому ресурсу.

Тело ответа

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

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

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

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

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

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

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

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

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

Повысьте безопасность на сетевых портах с Selectel

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

Выбрать

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

Как отправить 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-запрос и получить ответ от сервера.

Решения для управления данными в облаке

Новый «магический квадрант» Gartner для основных систем хранения, по-прежнему лидер

Нам лестно быть №1 в сценариях использования облачных ИТ-операций и контейнеров. Магический квадрант Gartner 2022 для основных систем хранения, 17 октября 2022 г., Джефф Фогель, Джозеф Ансворт, Чандра Мукхьяла.

GARTNER и Magic Quadrant являются зарегистрированными товарными знаками и знаками обслуживания компании Gartner, Inc. и/или ее дочерних компаний в США и других странах и используются здесь с разрешения. Все права защищены.

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

Читать блогarrow_forward

Встречайте следующую эволюцию облака

Мы помогаем облаку раскрыть весь свой потенциал

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

Встречайте эволюционировавшее облакоarrow_forward

Празднуем.

.. 100 дней

Мы рады нашим клиентам. Насколько взволнован? Мы посвящаем следующие 100 дней их празднованию. Как они меняют наш мир к лучшему. Оказывая реальное влияние на жизнь людей. И как они используют данные, чтобы сделать все это возможным.

• См. влияние NetApparrow_forward

Теперь мы можем перемещать огромные объемы данных на высокой скорости… через периферию, ядро ​​и облако…

Фридеманн Курц, руководитель ИТ-отдела автоспорта, Porsche

Узнайте большеarrow_forward 100% время безотказной работы

Porsche добился 100% времени безотказной работы после партнерства с NetApp.

Технологии важны для нас. Инновации являются краеугольным камнем. И именно поэтому партнерство с NetApp так важно. Мы верим в видение NetApp.

Кейт Суонборг, старший вице-президент по технологическим коммуникациям и стратегическим альянсам, DreamWorks

Прочтите их данные 268 миллионов файлов

DreamWorks использовала системы NetApp® AFF и FAS при создании фильма The Boss Baby: Family Business .

Благодаря объединению активов решений NetApp в Google Cloud нет необходимости редактировать приложения при их переносе в облако.

Франсуа-Ксавье Дельмер, руководитель Carrefour Build to Cloud

Погрузитесь в эту цифровую трансформациюarrow_forward 100 % облачных технологий к 2026 году

Экономия времени и операций благодаря NetApp помогла группе Carrefour реализовать свои цифровые амбиции, сразу же перенеся более 30 % своих данных в облако.

Мы выбрали NetApp AFF и FAS в качестве оптимального хранилища для нашей платформы KaaS и внедрили CSI-совместимый инструмент Trident, предоставленный NetApp.

Г-н Аки Нумата Руководитель, Отдел хранения 1, Отдел эксплуатации объектов, Технологическая группа, Yahoo Japan Corporation

Откройте для себя это решение для динамического хранения данныхarrow_forward 860+
экземпляров Kubernetes,
200 000+
контейнеров

Внедрение систем хранения NetApp AFF и FAS с Astra Trident позволило Z Lab Yahoo Japan использовать постоянное хранилище в своей инфраструктуре KaaS.

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

Рохит Агравал, глобальный руководитель отдела облачных вычислений и центров обработки данных, Siemens Healthineers

Изучите эту облачную стратегиюarrow_forward Снижение затрат на многоуровневое хранение данных на 50%

Чтобы лучше понять тело и его лечение, Siemens Healthineers обратилась к NetApp за гибкостью данных в локальной среде и в облаке.

Облачные службы

Создайте масштабируемое мультиоблако, объединенное со всеми основными поставщиками облачных услуг.

• Решения для облака

Гибридные облачные решения

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

• Предложения гибридного облака

Локальное хранилище

Модернизируйте свою среду хранения с помощью выбора №1 для безопасного хранения данных.

• Модернизация в локальной среде

Найдите инновационное решение для любых ваших потребностей в хранении данных

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

• Выберите лидера отрасли arrow_forward

Бизнес-решения

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

Круглые столы сообщества

Узнайте от лидеров отрасли обо всем, что связано с NetApp, сосредоточившись на выбранной вами теме, со временем для вопросов.

arrow_forward

Промышленность

Подходим ли мы для решения задач вашей компании с данными? Узнайте, в каких отраслях используются продукты NetApp.

arrow_forward

Истории клиентов

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

Просмотреть историиarrow_forward

Образование

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

Планируйте ростarrow_forward

Разработчики

Ресурсы, чтобы продукты NetApp работали для вас наилучшим образом, особенно для технических специалистов.

Центр знаний

Просматривайте статьи NetApp по темам и будьте в курсе обновлений и функций продуктов.

arrow_forward

Документация

Технические руководства для решений NetApp для обработки данных, созданные самими разработчиками продукта.

arrow_forward

Поддержка

Если хотите, отправьте нам электронное письмо. Облачный эксперт ответит своевременно.

Электронная почта NetApparrow_forward

Сообщество

NetApp и клиенты помогают друг другу находить ответы в обсуждениях.

Принять участиеarrow_forward

Внутри NetApp

Подготовьте свою инфраструктуру к будущему

Непревзойденная гибкость хранения, которая адаптируется к изменяющимся потребностям.

• Узнайте больше о NetApp Advancearrow_forward

Доступная корпоративная флэш-память

Получите скорость и проверенную защиту без больших затрат.

• Ознакомьтесь с AFF A-Seriesarrow_forward

Улучшение моделей ИИ с помощью системы хранения NetApp

IDC призывает к программно-определяемой масштабируемой инфраструктуре хранения.

• Читать отчет IDCarrow_forward

GigaOm: NetApp «устанавливает планку»

Мы снова признаны лидером в области облачных хранилищ файлов.

• Читать блогarrow_forward

Хотите свою собственную историю успеха?

Если у вас есть вопросы или вы готовы приступить к работе, специалисты NetApp всегда рядом.

Чат с NetApparrow_forward

Настроить виртуальный брифинг

Виртуально проведите время с нашими руководителями и экспертами и обсудите текущие и будущие потребности бизнеса.

Присоединяйтесь к toucharrow_forward

Тест-драйв нашей продукции

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

Пройти тест-драйвarrow_forward

Документация

Техническая документация по всем предложениям NetApp, от хранилища данных до облака.

• Получите техническую информациюarrow_forward

Поиск и устранение неисправностей

Возникли проблемы с продуктом NetApp? Просмотрите статьи, которые могут помочь в решении вашей проблемы.

• Начать поискarrow_forward

Обучение

Сертификаты и карьерный рост для специалистов по данным и ИТ.

• Изучить обучениеarrow_forward

FileZilla — бесплатное решение для FTP

Реклама:

Добро пожаловать на домашнюю страницу FileZilla®, бесплатного решения для FTP. Клиент FileZilla поддерживает не только FTP, но и FTP через TLS (FTPS) и SFTP. Это программное обеспечение с открытым исходным кодом, распространяемое бесплатно в соответствии с условиями Стандартной общественной лицензии GNU.

Мы также предлагаем FileZilla Pro с дополнительной поддержкой протоколов для WebDAV, Amazon S3, Backblaze B2, Dropbox, Microsoft OneDrive, Google Drive, Microsoft Azure Blob and File Storage и Google Cloud Storage.

И последнее, но не менее важное: FileZilla Server — это бесплатный FTP- и FTPS-сервер с открытым исходным кодом.

Поддержка доступна на наших форумах, вики, а также в средствах отслеживания ошибок и запросов функций.

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

Ссылки для быстрого скачивания

Выберите клиент, если хотите передавать файлы. Получите сервер, если вы хотите сделать файлы доступными для других.

Новости

03.03.2023 — Клиент FileZilla 3.63.2.1 выпущен

Исправления и мелкие изменения:

• macOS: несколько исправлений рендеринга в темном режиме
• macOS: отключить автоматическую замену кавычек/тире в полях ввода текста
• MSW: исправлена ​​проблема с Drag&Drop to Explorer в системах, использующих сокращенные пути 8.3 в переменных среды
• MSW: если FileZilla была установлена ​​только для текущего пользователя, обновление с помощью установщика теперь пропускает приглашение UAC
.
• Обновлено до libfilezilla 0.41.1 для исправления редкого сбоя
• Официальные двоичные файлы теперь собираются на основе GnuTLS 3.8.0

20 февраля 2023 г. — FileZilla Server 1.6.7 выпущен

Исправления и незначительные изменения:

• Исправлен уровень ведения журнала в диалоговом окне настроек интерфейса администрирования, который изначально всегда отображал отладку
• Исправлен сбой из-за отсутствия синхронизации при добавлении воркеров аутентификации
• Обновлено до GnuTLS 3.8.0

01.02.2023 — FileZilla Server 1.6.6 выпущен

Исправления и небольшие изменения:

• Исправлен сбой при отмене регулируемой аутентификации

16.07.2020 — FileZilla Pro добавляет поддержку Keystone V3, общего доступа к OneDrive и Amazon STS

Путем добавления поддержки службы идентификации OpenStack Swift Keystone v3, общего доступа к OneDrive и Amazon Secure Token Service (STS).