Исчерпывающий список кодов ошибок http

Причины долгого ожидания обработки заказа

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

Загруженность магазина

Магазин может быть перегружен заказами, что замедляет обработку каждого заказа.

Ошибки в информации

Неверно указанный номер телефона или адрес могут привести к задержкам.

Возможные причины долгой обработки

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

• Ошибки в коде программы: неэффективный алгоритм обработки или долгие операции с базой данных.

• Проблемы с сервером или сетью: сбои или нестабильное соединение могут вызывать задержки.

• Очередь задач: большое количество задач в очереди может замедлить обработку новых запросов.

• Недостаточные ресурсы сервера: нехватка мощности для обработки запросов.

Как ускорить процесс

• Проверьте правильность заполнения всех форм и документов.
• Свяжитесь с магазином для уточнения и исправления неверной информации.

Ускорение процесса обработки запроса

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

Действия для ускорения процесса обработки запроса

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

1. Будьте внимательным и вежливым при общении с контактными лицами или службой поддержки. Чем более четко и точно будет представлена информация и чем лучше будет установлена коммуникация, тем скорее будет выполнена ваша просьба.

2. Регулярно проверяйте статус запроса, сообщайте обо всех изменениях или обновлениях в своей ситуации.

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

Влияющие факторы на скорость обработки запроса

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

Потенциальные проблемы с обработкой запроса

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

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

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

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

## Ускорение процесса обработки запроса

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

### Действия для ускорения процесса обработки запроса

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

1. **Будьте внимательным и вежливым** при общении с контактными лицами или службой поддержки. Чем более четко и точно будет представлена информация и чем лучше будет установлена коммуникация, тем скорее будет выполнена ваша просьба.

2. **Регулярно проверяйте статус запроса**, сообщайте обо всех изменениях или обновлениях в своей ситуации. 

3. **Своевременно сообщайте об ошибках или изменениях** в документах или ситуации, чтобы избежать задержек или недоразумений.

### Влияющие факторы на скорость обработки запроса

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

## Потенциальные проблемы с обработкой запроса

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

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

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

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

Ускорение процесса обработки заказа

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

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

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

3. Обращение к службе поддержки: если статус не меняется долгое время, проверьте правильность данных, свяжитесь со службой поддержки и оставайтесь терпеливым.

Решение проблемы с задержками

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

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

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

3. Терпение: в случае задержек, возможно, процесс требует больше времени из-за большой загрузки или других факторов, поэтому оставайтесь терпеливыми.

Протокол передачи гипертекста

HTTP (HyperText Transfer Protocol) – это протокол передачи гипертекста, используемый для передачи произвольных данных. В начале своего развития он работал с гипертекстовыми документами в формате HTML, но постепенно стал работать с различными данными.

Таблица методов HTTP

Статус кодов HTTP

Заключение

HTTP – это протокол прикладного уровня, который позволяет обмениваться текстовой информацией через интернет. Зная основы работы с запросами, можно более эффективно и безопасно взаимодействовать с различными веб-ресурсами. Описание структуры запроса и кодов статуса поможет как новичкам, так и опытным разработчикам в успешном взаимодействии с серверами и сайтами.

Версии HTTP

HTTP/1.1 – это один из наиболее стабильных протоколов подключения. Он имеет несколько проблем:

Перечисленные проблемы удалось устранить вместе с HTTP/2. Теперь информация разбивается на фреймы, встраиваемые непосредственно в поток информации.

Заголовки

HTTP-заголовок – это «длинный текст», сформированный в формате «Имя-Заголовок-Значение» с двоеточием в виде разделяющего символа. Название заголовка запроса не учитывает регистр. Согласно действующим негласным правилам, принято каждое отдельное слово в такой записи указывать с заглавной буквы.

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

Заголовки делятся на несколько видов:

Выше – примеры наиболее распространенных заголовков запроса.

Тело запроса

Заключительная часть посылаемой на сервер «команды». Может отсутствовать у некоторых запросов: het, options, delete, head. Некоторые такие «команды» умеют отправлять данные непосредственно на серверную сторону. Наиболее распространенным вариантом является post.

Ответы HTTP

HTTP-ответ – это сообщение, которое будет отправляться сервером клиенту на посланную для обработки «команду». Его структура окажется точно такой же, как и в случае с HTTP Request: стартовая строчка, заголовок и тело.

Тело ответа

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

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

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

Выше можно увидеть несколько наиболее распространенных в ответах заголовков.

Строка статуса ответа

Строка статуса или status line – это компонент, который включает в себя:

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

Типы кодов

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

1xxИнформативные сообщения. На обработку «команды» такие коды никак не влияют.

2xxКоды, которые будут возвращаться при успешной обработке «команды».

3xxКоды, используемые для перенаправления пользователя.

4xxError. Коды, указывающие на то, что клиент сформировал некорректный запрос.

5xxПоказываются, если произошла ошибка сервера.

Далее более подробно будут рассмотрены категории 4xx и 5xx. Они помогут понять, когда и почему необходимо повторить запрос, указанный в заголовке.

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

К клиентским ошибкам (типа 4xx) относят:

Перечисленные ошибки не являются исчерпывающими. Здесь можно увидеть еще несколько их примеров.

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

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

К числу серверных ошибок относят:

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

P. S. Интересуют компьютерные сети, сетевые технологии, протоколы передачи данных? Обратите внимание на следующие курсы в Otus:

Управление статусами заявок

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

Форма создания / редактирования статуса заявки

В форме редактирования статуса можно изменить следующие параметры: 1. Наименование – отображаемое имя заявки.

2. Цвет ярлыка – позволяет выбрать цвет ярлыка статуса в окне цветовой палитры.

3. Панель доступности – здесь собраны следующие настройки:

Активна – данный переключатель позволяет включать / выключать статус, выключенный статус будет недоступен для всех в выпадающих списках.

Скрыть на главной панели – этот переключатель означает, что заявки с данным статусом не отображаются в списке заявок. Это может быть полезно для отображения только заявок со значимыми статусами.

Заморозить выполнение заявки – этот переключатель означает, что заявка с данным статусом перестает участвовать в автоматической проверке, но при этом, сроки метрик не сдвигаются и при смене статуса проверка снова будет учитывать метрики и считать просроченные заявки.

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

4. Действия заявки – предопределенное действие с заявкой, которое будет использовано при выборе данного статуса. Доступны следующие действия:

Заявка открыта – это действие означает, что заявка только что создана и требует обработки со стороны исполнителей.

Заявка в работе – это действие означает, что заявка принята исполнителем в работу и получает время и дату фактического начала работ.

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

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

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

Заявка отменена – это действие означает, что выполнение заявки отменено по какой-либо причине и дальнейшая автоматическая обработка этой заявки не производится.

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

Заявка отложена – позволяет в момент перевода заявки в данный статус отложить выполнение заявки до срока указанного в форме выбора.

Заявка открыта повторно – при переводе заявки в данный статус заявка возобновляет работу по заявке, очищая только дату фактического выполнения. Позволяет заказчику открыть снова работу по заявке, если она была выполнена некорректно.

Заявка приостановлена – данный статус позволяет поставить заявку на паузу, при этом время нахождения на паузе, сдвигает все дедлайны на этот срок, учитывая только рабочее время. Счетчик времени выполнения тоже останавливается.

Архивировать заявку – данный статус переводит заявку в архивные и она не отображается в общем списке заявок и перестает проходить проверки на дедлайны и другие метрики SLA.

Другой – это действие может принимать любые промежуточные статусы, которые могут потребоваться в процессе обработки заявки, например, статус «Требует уточнения» может быть установлен исполнителем для получения разъяснений от заказчика, при этом сроки метрик не меняются.

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

6. E-mail и SMS шаблоны – позволяют выбрать для каждого канала уведомления и типа пользователя отдельный шаблон уведомления, отправляемого при смене статуса. Данные шаблоны редактируются в справочниках Шаблоны E-mail уведомлений и Шаблоны SMS-уведомлений.

7. Роли – вы можете выбрать роли, которым будет доступно отображение данных статусов при создании / редактировании заявки.

8. Список ролей – в этом списке отображаются роли, которым уже назначен доступ к данному статусу.

9. Правила перехода – правила перехода позволяют указать для каждого статуса возможность перевода заявки в другие статусы, для каждой роли в системе. Если правила не указаны, то применяются правила доступа на основе роли из пункта 8. Возможно выбрать несколько статусов для перехода.

В ITSM-системе применяются понятия жизненный цикл и статус запроса. Статусная модель имеет большое значение, ведь в ней закладываются логика и правила, по которым будут обрабатываться заявки пользователей. Зачастую потребности в специфических настройках у клиентов шире, чем предлагает ИТ-продукт. Возникает необходимость выбора между универсальным подходом к настройкам и специализацией, когда учитываются процессы клиента и обеспечивается работоспособный workflow, но «приносятся в жертву» общие принципы построения системы.

В статье поговорим про поиск баланса между универсальностью и уникальными настройками в ITSM-системе. Что лучше — получить широкий охват процессов управления или сразу адаптировать их под задачи клиента. Для этого рассмотрим, какие разные подходы мы использовали в no-code решении Naumen Service Desk Pro при настройке жизненных циклов запросов и как это помогло трансформировать продукт.

Кастомизация под клиента

Изначально в проектах внедрения Naumen Service Desk Pro делалась ставка на возможности платформы, которая предоставляет различные общей функциональности и жизненных циклов (ЖЦ).

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

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

Создание универсального шаблона

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

Такие выводы позволили сформировать новое видение — попробовать создать универсальный шаблон жизненного цикла. Это как сконструировать подходящий всем «доспех», да и делать его быстрее.

Настройка набора статусов, который можно использовать как универсальный шаблон

Подобную реализацию можно описать следующим образом:

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

В итоге разработанный шаблон не мог претендовать на универсальность. Требовался другой сценарий, который охватывал бы больше клиентских кейсов и оставался при этом продуктовым. Нужно решение, которое позволяло бы без привлечения вендора перенастраивать ЖЦ так, как это необходимо .

Масштабирование и тиражирование

По мере развития продукта и ухода от кастомизации под конкретного клиента возникли другие вопросы, которые не решались универсальным шаблоном ЖЦ в запросах. Вот некоторые из них:

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

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

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

Гибкий подход к настройкам

При аналитике нового механизма решили, что в настройке ЖЦ отказываемся от устойчивых линий поддержки и добавляем гибкости. Это позволит создавать столько рабочих статусов, сколько необходимо. Вместе с тем у каждой услуги могут быть свои требования к ЖЦ. Тогда настройка масштабируется в зависимости от конкретного вида обращения до всего процесса.

В результате возникла идея добавить в продукт пользовательские статусы, которые будут создавать сами менеджеры услуг и ассоциироваться с системным статусом. Далее в Naumen SD Pro на этот статус завязывается вся необходимая логика.

Гибкий подход к настройке статусов в системе автоматизации

Визуализация статусной модели в Naumen Service Desk Pro

Новая реализация позволила найти баланс между общими продуктовыми принципами и адаптацией системы под задачи клиентов.

К выводам

Последовательная «эволюция» настройки workflow запросов в Naumen SD Pro помогла решить множество недостающих кейсов при автоматизации бизнес-процессов наших клиентов. Одновременно мы сохранили продуктовый подход, что дало масштабируемость механизма и поддержку регулярных обновлений ITSM-системы.

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

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

Коды состояния определены в RFC 9110.

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

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

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

101 Switching Protocols

Этот код отправляется в ответ на заголовок запроса Upgrade (en-US) от клиента и указывает протокол, на который переключается сервер.

102 Processing (en-US) (WebDAV (en-US))

Сервер получил и обрабатывает запрос, но ответа пока нет.

103 Early Hints

Этот код в первую очередь предназначен для использования с заголовком Link (en-US), позволяя пользовательскому агенту начать предварительную загрузку (en-US) ресурсов или осуществить предварительное соединение (en-US) к источнику ресурсов, пока сервер готовит ответ.

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

Запрос успешно выполнен. Значение результата «успех» зависит от метода HTTP:

Запрос выполнен успешно, и в результате был создан новый ресурс. Обычно это ответ, отправляемый на запросы POST или PUT.

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

Возвращенные метаданные не полностью совпадают с теми, которые доступны на исходном сервере, а получены из другого источника. Чаще всего это используется для зеркал или резервных копий ресурсов. За исключением таких случаев предпочтительнее использовать ответ 200 OK.

204 No Content

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

205 Reset Content

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

206 Partial Content

Этот код ответа используется, когда от клиента отправляется заголовок Range для запроса только части ресурса.

207 Multi-Status (en-US) (WebDAV (en-US))

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

208 Already Reported (en-US) (WebDAV (en-US))

226 IM Used (en-US) (HTTP Delta encoding)

Используется для ответа на запросы GET в тех случаях, когда сервер хочет отправить только изменённую часть ресурса (то есть «дельту»).

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

300 Multiple Choices

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

301 Moved Permanently

URL-адрес запрошенного ресурса был изменен навсегда. Новый URL-адрес указан в ответе.

URI запрошенного ресурса был временно изменен. В будущем могут быть внесены дальнейшие изменения в URI. Следовательно, этот же URI должен использоваться клиентом в будущих запросах.

303 See Other

Клиенту необходимо получить запрошенный ресурс по другому URI с помощью запроса GET.

304 Not Modified

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

305 Use Proxy

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

Этот код ответа зарезервирован. Использовался в предыдущей версии спецификации HTTP/1.1.

307 Temporary Redirect

Клиенту необходимо получить запрошенный ресурс по другому URI тем же методом, который использовался в предыдущем запросе. Он имеет ту же семантику, что и код ответа 302 Found, за исключением того, что пользовательский агент не должен изменять используемый метод: если в первом запросе использовался POST, то POST должен использоваться и во втором запросе.

308 Permanent Redirect

Ресурс теперь находится по другому URI, указанному в заголовке ответа Location. Он имеет ту же семантику, что и код ответа 301 Moved Permanently, за исключением того, что пользовательский агент не должен изменять используемый метод: если в первом запросе использовался POST, то POST должен использоваться и во втором запросе.

Ошибки клиента

400 Bad Request

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

Хотя стандарт HTTP определяет этот ответ как «неавторизованный», семантически он означает «неаутентифицированный». Это значит, что клиент должен аутентифицировать себя, чтобы получить запрошенный ответ.

402 Payment Required

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

Клиент не имеет прав доступа к контенту, то есть он неавторизован, поэтому сервер отказывается предоставить запрошенный ресурс. В отличие от 401 Unauthorized, личность клиента известна серверу.

404 Not Found

Сервер не может найти запрошенный ресурс. В браузере это означает, что URL-адрес не распознан. В API это также может означать, что адрес правильный, но ресурс не существует. Сервер также может отправить этот код ответа вместо 403 Forbidden, чтобы скрыть существование ресурса от неавторизованного клиента. Это самый известный код ответа из-за его частого появления в сети.

405 Method Not Allowed

Метод запроса известен серверу, но не поддерживается целевым ресурсом. Например, API может не разрешать вызов DELETE для удаления ресурса.

406 Not Acceptable

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

407 Proxy Authentication Required

Этот код ответа похож на 401 Unauthorized, но аутентификация должна выполняться через прокси-сервер.

408 Request Timeout

Сервер может отправить этот код ответа при неиспользовании соединения, даже без предварительного запроса со стороны клиента. Он означает, что сервер хотел бы закрыть это соединение. Этот ответ используется сравнительно часто, поскольку некоторые браузеры (такие как Chrome, Firefox 27+ или IE9) для ускорения используют механизмы предварительного подключения HTTP. Некоторые серверы просто закрывают соединение, не отправляя это сообщение.

Запрос конфликтует с текущим состоянием сервера.

Запрошенное содержимое было удалено с сервера, и отсутствует возможность переадресации. Ожидается, что клиенты удалят свои кеши и ссылки на этот ресурс. Спецификация HTTP предполагает, что этот код ответа будет использоваться для «ограниченных по времени или рекламных услуг». API не обязаны указывать ресурсы, которые были удалены, с помощью этого кода.

411 Length Required

Запрос отклонён, потому что сервер требует указание поля заголовка Content-Length, но оно не определено.

412 Precondition Failed

Клиент указал в заголовках запроса условия, которым сервер не соответствует.

413 Payload Too Large

Размер объекта запроса превышает ограничения, определенные сервером. Сервер может закрыть соединение или вернуть поле заголовка Retry-After.

414 URI Too Long

Запрошенный клиентом URI слишком длинный для того, чтобы сервер смог его обработать.

415 Unsupported Media Type

Запрос отклонён, потому что медиа формат запрашиваемых данных не поддерживается сервером.

416 Range Not Satisfiable

Сервер не может корректно обработать запрос с учётом диапазона, указанного в поле заголовка Range.

417 Expectation Failed

Сервер не может выполнить ожидание, указанное в поле заголовка запроса Expect.

418 I’m a teapot

«Шуточный» ответ: сервер отклоняет попытку заварить кофе в чайнике.

421 Misdirected Request (en-US)

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

422 Unprocessable Content (WebDAV (en-US))

Запрос сформирован правильно, но его невозможно выполнить из-за семантических ошибок.

423 Locked (en-US) (WebDAV (en-US))

Запрашиваемый ресурс заблокирован.

424 Failed Dependency (en-US) (WebDAV (en-US))

Запрос не выполнен из-за проблем в предыдущем запросе.

425 Too Early

Клиент отправил порцию данных слишком рано, до того как сервер установил безопасное соединение.

426 Upgrade Required

Сервер отказывается выполнять запрос с использованием текущего протокола, но может быть готов сделать это после смены протокола на указанный в заголовке ответа Upgrade (en-US).

428 Precondition Required

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

429 Too Many Requests

Пользователь отправил слишком много запросов в определённый промежуток времени.

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

451 Unavailable For Legal Reasons

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

Ошибки сервера

500 Internal Server Error

На сервере произошла ошибка, в результате которой он не может успешно обработать запрос.

501 Not Implemented

Метод запроса не поддерживается сервером и поэтому он не может быть обработан. Методы GET и HEAD должны всегда поддерживаться сервером и для них не должен возвращаться этот код.

502 Bad Gateway

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

503 Service Unavailable

Сервер не готов обработать запрос в данный момент. Распространёнными причинами являются техническое обслуживание или перегрузка сервера. Вместе с таким ответом следует отправлять удобную для пользователя страницу с объяснением проблемы, а также HTTP-заголовок Retry-After с расчётным временем решения проблемы. Кроме того, полезно отправлять заголовки с информацией о кешировании, поскольку эти временные ответы обычно не следует кэшировать.

504 Gateway Timeout

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

505 HTTP Version Not Supported

Используемая в запросе версия HTTP не поддерживается сервером.

506 Variant Also Negotiates (en-US)

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

507 Insufficient Storage (en-US) (WebDAV (en-US))

Запрос не выполнен, потому что серверу не удалось сохранить данные.

508 Loop Detected (en-US) (WebDAV (en-US))

Запрос не выполнен, потому что на сервере был обнаружен бесконечный цикл обработки данных.

510 Not Extended (en-US)

Для выполнения запроса необходимо его расширить.

511 Network Authentication Required

Клиенту необходимо пройти аутентификацию для получения доступа к сети.

Совместимость с браузерами

BCD tables only load in the browser

Довольно часто вы можете столкнуться с такими ошибками, как 404 и 301, но есть много кодов статуса HTTP, с которыми вы, вероятно, не знакомы.

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

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