Содержание

200 — это хорошо или это плохо? / Хабр

В этой трехминутной статье я хочу затронуть наболевшую тему.

Речь пойдет о статус коде HTTP 200 и ошибках в ответе.

HTTP/1.1 200 OK

{
  "error": {
    code: 2019,
    message: "Validation failed: field 'size' is invalid: the value is not a number"
  }
}

Нормально ли возвращать такой код, если возникла ошибка?

Нет? Да? Ну-ка давайте разберемся.

Случай 1. HTTP 200 и batch операция

Допустим отправляется один запрос. Запрос выполняется успешно. Возвращаем код 200. Ответ не содержит информации об ошибке. С этим случаем всё предельно просто и понятно. А что делать если требуется выполнить batch операцию?

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

Запрос выглядит примерно так:

{
  "sources": [
    {"image": "http://myserver.com/image1.jpg"},
    {"image": "http://myserver.com/image2.jpg"},
    {"video": "http://myserver.com/video.jpg"}
  ]
}

Предположим, по какой-то причине (например, кончилось место на сервере) видео загрузить не удалось. Что бы вы вернули в таком случае? 2xx или 4xx или 5xx? Сервер, отвечает примерно вот так:

HTTP/1.1 200 OK

{
  "results": [
    { "status": "ok", "id": 312 },
    { "status": "ok", "id": 313 },
    { "status": "fail", "error": "NO SPACE" }
  ]
}

Некоторые сервисы (и вполне известные) действуют также. Отвечают 200. А в ответе возвращают список команд, которые выполнить не получилось.

Случай 2. HTTP 200 и ошибки в ответе

Пришёл запрос. Запрос зафейлился. Например, мы забыли указать какое-то поле. Или дату отправили не в миллисекундах, а как строку. Тут-то точно не надо возвращать 200! Но увы и нет.

Где-то на просторах интернета я встречал проекты на github и bitbucket, которые специально предназначены для таких вот случаев. В них просто вшиты возможные варианты и шаблоны. Можно их достаточно легко встроить в свой проект и как бы быть готовым к разного рода «падениям» запросов. Но есть одно но.

В такие моменты твой код становится уродливым. Ты ему говоришь:

— Cлушай, у нас тут есть один внешний API. Он в целом нормальный. Только надо внимательно смотреть что в ответе приходит. Если там ответ содержит поле «error», то значит запрос сломался.

— Но ведь для этого же есть 4xx и 5xx! Да кто вообще так делает?!

— Тише-тише. Не надо так громко. Он может услышать. Пожалуйста, будь добрее к нему. И просто смотри не только на статус код, но и на ответ, пожалуйста.

— Ладно…

HTTP 200 — это просто статус

Ну 200 и 200. Ну не запилили. Или не успели. Или вообще не будут. Ну и что?! Написал json парсер и всё!

Как бы да, но я хочу знать почему. Забыли? Забили? Не успели? Не знали?

Возможно я что-то упускаю. Или не знаю. Хочу ваше мнение. Срочно. Всем добра и выходных на выходных.

REST страсти по 200 / Хабр

Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т.д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что 🙂

В общем, именно судьба той статьи побудила меня написать эту. И я очень надеюсь, что она будет полезна и прояснит многое.

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

HTTP

Первым делом нужно очень четко разделить слои. Слой транспорта — http. Ну и собственно REST. Это фундаментально важная вещь в принятии всего и “себя” в нем. Давайте сначала поговорим только о http.

Я использовал термин “слой транспорта”. И я не оговорился. Все дело в том, что сам http реализует функции транспортировки запросов к серверу и контента к клиенту независимо от tcp/ip. Да, он базируется на tcp/ip. И вроде, нужно считать именно его транспортным. Но, нет. И вот почему — сокет-соединения не являются прямыми, т.е. это не соединение клиент-сервер. Как http запрос, так и http ответ могут пройти длинный путь через уйму сервисов. Могут быть агрегированы или напротив декомпозированы. Могут кэшироваться, могут модифицироваться.

Т.е. у http запроса как и http ответа есть свой маршрут. И он не зависит ни от конечного бэка, ни от конечного фронта. Прошу на это обратить особое внимание.

Маршруты http не являются статическими. Они могут быть очень сложными. Например, если в инфраструктуру встроен балансировщик, полученные запросы он может отправить на любую из нод бэка. При этом, сам бэк может реализовывать собственную стратегию работы с запросами. Часть из них пойдет на микросервисы напрямую, часть будет обработана самим web-сервером, часть дополнена и передана кому-то еще, а часть выдана из кэша и т.п. Так работает Интернет. Ничего нового.

И тут важно понять — зачем нам коды ответов? Все дело в том, что вся вышеописанная модель принимает решения на их базе. Т.е. это коды, позволяющие принимать инфраструктурные и транспортные решения в ходе маршрутизации http.

К примеру, если балансировщик встретится с кодом ответа от бэка 503, при передаче запроса, он может принять это за основание считать, что нода временно недоступна. Отмечу, что в ответе с кодом 503 предусмотрен заголовок Retry-After. Получив из заголовка интервал для повторного опроса, балансировщик оставит ноду в покое на указанный срок и будет работать с доступными. Причем, подобные стратегии реализуются “из коробки” web-серверами.

Небольшой офтопик для глубины понимания — а если нода ответила 500? Что должен сделать балансировщик? Переключать на другую? И многие ответят — конечно, все 5xx основание для отключение ноды. И будут неправы. Код 500 это код неожиданной ошибки. Т.е. той, которая может больше никогда и не повториться. И главное, что переключение на другую ноду может ничего и не изменить. Т.е. мы просто отключаем ноды без малейшей пользы.

В случае с 500 нам на помощь приходит статистика. Локальный WEB-сервер ноды, может переводить саму ноду в статус недоступности при большом количестве ответов 500. В этом случае, балансировщик обратившись на эту ноду, получит ответ 503 и не будет ее трогать. Результат тотже, но теперь, такое решение осмысленно и исключает “ложные” срабатывания.

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

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

REST

Задам риторический вопрос — что это такое? И что вы ответили себе на него? Не буду давать ссылки на очевидные пруфы, но скорее всего не совсем то, чем он является по сути 🙂 Это лишь идеология, стиль. Некие соображения на тему — как лучше общаться с бэком. И не просто общаться, а общаться в WEB инфраструктуре. Т.е. на базе http. Со всеми теми “полезными штуками”, о которых я написал выше. Конечные решения по реализации вашего интерфейса остаются всегда за вами.

Вы задумывались почему не придуман отдельный транспорт для REST? Например, для websocket он есть. Да, он тоже начинается с http, но потом, после установки соединения, это вообще отдельная песня. Почему бы не сделать такую же для REST?

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

Отсюда следует простой, очевидный вывод — все, что присуще http, присуще и REST. Это неотделимые сущности. Нет отдельного заголовка REST, нет даже намека на то, что REST это REST. Для любого сервера REST запрос ровно такой же, как и любой другой. Т.е. REST это только то, что у нас “в голове”.

Коды ответа http в REST

Давайте поговорим о том, каким же кодом должен отвечать ваш сервер на REST запрос? Лично мне кажется, что из всего выше написанного уже очевиден ответ, что т.к. REST не отличается от любого другого запроса, он должен быть подчинен ровно тем же правилам. Код ответа — неотъемлемая часть REST и он должен быть релевантен сути ответа. Т.е. если не найден объект по запросу, это 404, если клиент обратился с некорректным запросом 400 и т.д. Но, чаще всего, дебаты на сём не заканчиваются. Поэтому, продолжу и я.

Можно ли отвечать на всё кодом 200? А кто вам запретит? Пожалуйста… код 200 такой же код как и другие. Правда, в основе такого подхода лежит очень простой тезис — моя система идеальная, у нее не бывает ошибок. Если вы человек, который может создавать такие системы — этому можно только позавидовать!

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

И так, принимая код 200 как единственно верный, мы берем на себя обязанности на разработку целого слоя (критического слоя) системы — обработку ошибок. Т.е. труд многих людей по разработке этого слоя отправляется в утиль. И начинается постройка своего “велосипеда”. Но эта мегастройка обречена на провал.

Начнем с кода. Если мы собираемся на все отвечать 200, нам самим придется обрабатывать ошибки. Классическим методом является try конструкции. Каждый сегмент кода мы оборачиваем дополнительным кодом. Обработчиками, которые что-то делают полезное. Например, что-то кладут в лог. Что-то важное. Что позволит локализовать ошибку. А если ошибка возникла не там где ее ожидали? Или если ошибка возникла в обработчике ошибки? Т.е. эта стратегия на уровне кода нерабочая априори. И в конце концов, обрабатывать ваши баги будет интерпретатор или платформа. ОС, наконец. Суть бага в том, что вы его не ждете. Не нужно его прятать, его нужно находить и фиксить. Поэтому, если на какие-то запросы REST ответит ошибкой 500 это нормально. И более того — правильно.

Давайте еще раз вернемся к вопросу — почему это правильно? Потому что:

  1. Код 500 это инфраструктурный маркер, на основании которого нода на которой возникает проблема может быть отключена;
  2. Коды 5xx это то, что мониторится и если такой код возникает, любая система мониторинга тут же вас известит об этом. И служба поддержки вовремя сможет подключиться к решению проблемы;
  3. Вы не пишите дополнительный код. Не тратите на это драгоценное время. Не усложняете архитектуру. Вы не занимаетесь несвойственными вам проблемами — вы пишите прикладной код. То, что от вас хотят. За что платят.
  4. Трейс который выпадет по ошибке 500 будет куда как полезнее, чем ваши попытки его превзойти.
  5. Если REST запрос вернет 500 код, фронт уже на моменте обработки ответа будет знать, по какому алгоритму его обрабатывать. Причем, суть дела никак не изменится, вы как ничего толкового не получили и с 200, так и с 500. Но с 500 вы получили профит — осознание того, что это НЕОЖИДАННАЯ ошибка.
  6. Код 500 придет гарантированно. Независимо от того насколько плохо или хорошо вы написали свой код. Это ваша точка опоры.

Отдельно забью гвоздь во все “тело” кода 200:

7. Даже если вы очень сильно постараетесь избежать иных кодов ответа от сервера кроме как 200 на ваши запросы, вы не сможете это сделать. Вам может ответить на ваш запрос любой сервер посредник, совершенно любым кодом. И вы ДОЛЖНЫ будете такой ответ обработать корректно.

Итого, на логическом уровне борьба за код 200 бессмысленна.

Теперь давайте вернемся к инфраструктурному уровню. Очень часто слышу мнение — код 5xx не прикладного уровня, его нельзя отдавать бэком. Кхм, ну… тут есть противоречие в самом утверждении. Отдавать можно. Но код этот не прикладного уровня. Вот так вернее. Для понимания этого, предлагаю рассмотреть кейс:

Вы реализуете шлюз. У вас несколько ДЦ, на каждом свой канал связи к некоему приватному сервису. Ну, к примеру, к платежке по VPN. И есть канал коммуникации с Интернет. Вы получаете запрос на операцию со шлюзом, но… сервис оказывается недоступен.

И так, что вы должны ответить? Кому? Это проблема именно инфраструктурная и, именно, бэк столкнулся с ней. Конечно, нужно смело отвечать 503. Эти действия приведут к тому, что нода будет отключена балансировщиком на какое-то время. При этом, балансировщик при правильной настройке, не разрывая соединение с клиентом, отправит запрос в другую ноду. И… конечный клиент, с великой долей вероятности получил 200. А не кастомное описание ошибки, которая ему ничем не поможет.

Где и какой код использовать

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

Есть принятые стандарты. Их можно легко найти и, опять же, не буду очевидные пруфы приводить. Но, приведу неочевидный — developer.mozilla.org/ru/docs/Web/HTTP/Status

Почему его? Все дело в том, что обработчики кода могут вести себя по разному, в зависимости от реализации и контекста “понимания кода”. К примеру, в браузерах есть стратегия кеширования, завязанная на коды ответа. А в некоторых сервисах есть свои, кастомные коды. Например, CloudFlare.

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

Корни зла

Уже третий проект, в который я прихожу страдает кодом 200 в REST. Именно страдает. Другого слова нет. Если вы внимательно прочли всё до текущего момента, вы уже понимаете, что как только проект начинает расти, у него появляется потребность в развитии инфраструктуры, в ее устойчивости. Код 200 убивает все эти потуги на корню. И первое, что приходится делать — ломать стереотипы.

Корень зла, мне кажется лежит в том, что код 500, это первое, что web-разработчик встречает в своей профессиональной деятельности. Это, можно сказать, детская травма. И все его старания поначалу сводятся к тому, чтобы получить код 200.

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

Далее, с развитием разработчика, у него возникают потребности в управлении багами собственного приложения. Но…, он не умеет пользоваться логами. Не умеет настраивать web-сервер. Он учится. И рождаются те самые «велики». Потому что, они ему доступны и он может их быстро сделать. Далее, на этот «велик» он монтирует новые колеса, усиливает раму и т.д. И этот велик становится его спутником на достаточно длительный промежуток времени, пока… пока у него не появляются реально сложные, многокомпонентные задачи. И тут, как говорится — вход в супермаркет с «великами» и на роликах запрещен.

P.S.: Автор упомянутой статьи восстановил ее из черновиков — habr.com/ru/post/440382, поэтому можно ознакомиться с ней тоже.

P.P.S.: Я постарался изложить все грани необходимости использования релевантных кодов ответа в REST. Я не буду отвечать на комментарии, прошу понять меня правильно. С большим вниманием буду их читать, но добавить мне нечего. Огромное спасибо за то, что вам хватило терпения прочесть статью!

Что означает код ответа сервера “200 OK”

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

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


Подпишись на рассылку и получи книгу в подарок!

Код ответа 200 — один из типов кодов HTTP, информирует пользователя об успешной обработке запроса. Исходя из статуса, сервер может предоставлять тело и заголовок сообщения.

Больше видео на нашем канале — изучайте интернет-маркетинг с SEMANTICA

Приведем пример. Вы отправили посылку в другой город. На почте вам выдали трек-номер для отслеживания. По нему вы смотрите, что с вашим отправлением — вот оно покинуло сортировочный центр вашего города, вот прибыло в другой. Вот его вручили адресату. Каждый раз система выдает вам статус в ответ на запрос.

Как это работает

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

HTTP — это специальный протокол для обмена данными между различными веб-серверами (браузер пользователя и веб-сервер, где находится сам сайт). То есть браузер направляет запрос к интересующему его серверу, это может быть действие или документ, а затем получает ответ. Если ответ на обращение положительный, отображается код ответа сервера 200 и начинается загрузка файла. Если отрицательный, то есть запрашиваемая страница не найдена или имеются проблемы в работе сервиса, выходит сообщение об ошибке.

Что означает код 200 для правильной индексации сайта

Категория серверных ответов 2хх является категорией «Success». Эта категория уведомляет пользователей о положительном результате. В частности, код “200 ОК” говорит пользователю, что его запрос успешно выполнен. Например, клиент запросил те или иные данные. Ответ сервера 200 означает, что эти данные отображены в заголовке или сообщении.

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

Важно проверить, не отдают ли несуществующие страницы код 200. Это возможно даже когда визуально вы видите на экране “404 — страница не найдена”. Причиной этой проблемы может стать неправильная настройка работы сайта. Если вы не хотите проблем с продвижением вашего ресурса — проверьте все типы страниц на корректный ответ сервера. Так вы сможете выявить страницы, которые только прикидываются нужными.

Как проверить коды ответов

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

На самом деле кодов ответа сервера большое количество, но самые часто встречающиеся следующие:

  • Если сначала страница отвечала на запрос кодом 200, благополучно проиндексировалась, но затем ее удалили, при переходе на нее будет отображаться код 404 (не найден).
  • Если вы используете временный редирект (302), то в индекс попадут оба адреса.
  • Если на веб-странице используется постоянный редирект, вы получите ответ с кодом 301. И поисковик будет индексировать только конечный адрес с нужным кодом.

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

Список кодов состояния HTTP сервера. Справочник кодов состояния HTTP сервера.

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. В завершении рассказа о кодах состояния HTTP сервера я составил небольшой справочник кодов состояния HTTP сервера, в котором вы можете найти список кодов состояния HTTP сервера, которые есть в стандарте HTTP 1.1.

Список информационных кодов состояния HTTP сервера

Содержание статьи:

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

Информационный код состояния Описание информационного кода состояния
100 Continue Информационный код состояния HTTP сервера  100: продолжай
Код состояния 100 говорит о том, что запрос получен, но находится в процессе обработки
101 Switching Protocols Информационный код состояния HTTP сервера  100: переключи протокол
Код состояния 101 говорит о том, что сервер переключает протокол

Справочник успешных кодов состояния HTTP сервера

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

Успешный код состояния Описание успешного кода состояния HTTP севера
200 OK Успешный код состояния HTTP сервера 200: хорошо
Код состояния 200 говорит клиенту о том, что его запрос удачно выполнен.
201 Created Успешный код состояния HTTP сервера 201: создан
Код состояния 201 сообщает нам о том, что новый ресурс был создан успешно.
202 Accepted Успешный код состояния HTTP сервера 202: принято
Код состояния 202 сообщает клиенту о том, что HTTP запрос успешно принят на обработку, но обработка еще не завершена, в этом случае сервер может отказать в обслуживание запроса клиента.
203 Non-authoritative Information Успешный код состояния HTTP сервера 203: не авторская информация
Код состояния 203 сообщает клиенту о том, что возвращенная в заголовке HTTP  объекта информация – это не оригинал, который есть на первоначальном сервере, а документ, собранный из локальных копий или копий третьей стороны, возможно даже, что данный документ — это кэш HTTP сервера.
204 No Content Успешный код состояния HTTP сервера 204: нет содержимого
Код состояния 204 говорит клиенту о том, что в ответном HTTP сообщении нет тела (про тело объекта HTTP).
205 Reset Content Успешный код состояния HTTP сервера 205: сбросить содержимое
Если браузер получит код состояния 205, то он должен очистить форму, чтобы дать пользователю ввести дополнительные данные.
206 Partial Content Успешный код состояния HTTP сервера 206: частичное содержимое
Код состояния 206 говорит браузеру о том, что HTTP сервер выполнил частичный GET запрос клиента (про методы HTTP). Чтобы получить такой код запрос клиента должен содержать поле заголовка Range, который указывает диапазон (вспоминаем диапазоны значений и HTTP параметры).

Список кодов перенаправления HTTP сервера

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

HTTP ответ Описание кода состояния перенаправления
300 Multiple Choices HTTP код перенаправления 300: множественный выбор
HTTP код состояния 300 говорит клиенту о том, что запрошенный ресурс имеет несколько представлений и клиент в праве выбрать одно из предлагаемых представлений.  Действует ограничение в пять адресов максимум и используется для обсуждения содержимого в HTTP.
301 Moved Permanently HTTP код перенаправления 301: постоянно перемещен
HTTP код состояния 301 говорит клиенту о том, что запрашиваемая страница была перенесена на новый адрес, обычно браузер автоматически переходит по новому адресу.
302 Found HTTP код перенаправления 302: временно перемещен
HTTP код состояния 302 говорит клиенту о том, что запрашиваемый ресурс был временно перемещен на новый адрес.
303 See Other HTTP код перенаправления 303: смотри другой
HTTP код состояния 303 говорит клиенту о том, что ответ на запрос может быть найден по другому URI (про URI в HTTP найдешь информацию здесь), новый запрос следует выполнять методом GET
304 Not Modified HTTP код перенаправления 304: не модифицирован
HTTP код состояния 304 говорит клиенту о том, что сервер выполнил условный GET запрос, но документ никак не изменился.
305 Use Proxy HTTP код перенаправления 305: используй прокси
HTTP код состояния 304 говорит клиенту о том, что запрошенный URL должен быть доступен через прокси, который указан в поле заголовка Location.
306 Unused HTTP код перенаправления 306: зарезервировано
Код состояния 306 использовался в прошлой версии HTTP протокола, на данный момент он не используется, но зарезервирован стандартом HTTP.
307 Temporary Redirect HTTP код перенаправления 307: временно перемещен
HTTP код состояния 307 говорит клиенту о том, что запрашиваемая страница временно переехала на новый адрес

Справочник HTTP кодов ошибок клиента

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

Код ошибки HTTP клиента Описание кода ошибки HTTP клиента
400 Bad Request Код состояния ошибки HTTP клиента  400: плохой запрос
Такой код состояния ошибки клиента вы можете увидеть тогда, когда сервер не понял ваш запрос из-за синтаксической ошибке в HTTP запросе.
401 Unauthorized Код состояния ошибки HTTP клиента  401: не авторизован
Такой код состояния ошибки клиента вы можете увидеть в том случае, если для доступа к ресурсу требуется аутентификация на HTTP сервере
402 Payment Required Код состояния ошибки HTTP клиента  402: требуется оплата
Этот код состояния ошибки клиента на данный момент пока не используется, он предназначен для платных сервисов, а не для хостингов и интернет-провайдеров.
403 Forbidden Код состояния ошибки HTTP клиента  403: запрещено
Такой код состояния ошибки клиента вы увидите в том случае, когда сервер вас прекрасно понял, но отказывается вам предоставлять доступ к ресурсу из-за того, что у вас недостаточно прав доступа из-за настроек безопасности HTTP сервера.
404 Not Found Код состояния ошибки HTTP клиента  404: не найдено
Самый популярный код состояния ошибки клиента. Вы его можете увидеть в том случае, когда ошиблись, вводя URL в браузере.
405 Method Not Allowed Код состояния ошибки HTTP клиента  405: метод не дозволен
Данный код состояния ошибки клиента можно увидеть в том случае, когда вы используете метод запроса, запрещенный в настройках HTTP сервера.
406 Not Acceptable Код состояния ошибки HTTP клиента  406: не приемлем
Этот код состояния вы увидите в том случае, когда HTTP сообщение вашего клиента содержит неправильные параметры для указанного в нем URI.
407 Proxy Authentication Required Код состояния ошибки HTTP клиента  407: требуется установления подлинности через прокси-сервер
Если вы видите этот код состояния ошибки клиента, то вам нужно пройти аутентификацию на прокси-сервере.
408 Request Timeout Код состояния ошибки HTTP клиента  408: истекло время ожидания запроса
Этот код состояния ошибки HTTP клиента вы увидите тогда, когда сервер устал ждать от вас сообщение.
409 Conflict Код состояния ошибки HTTP клиента  409: конфликт
Такой код состояния ошибки клиента будет появляться очень редко, когда будет происходить конфликт действий между двумя пользователями.
410 Gone Код состояния ошибки HTTP клиента  410: удален
А этот код состояния ошибки клиента будет показан сервером в том случае, когда ресурс был доступен по указанному URI, но теперь его там нет.
411 Length Required Код состояния ошибки HTTP клиента  411: требуется длина
Этот код состояния ошибки клиента появляется в том случае, когда серверу нужно обязательно указывать поле заголовка Content-Lenght
412 Precondition Failed Код состояния ошибки HTTP клиента  412: предусловие неверно
Сервер вернет HTTP ответ с таким кодом состояния в том случае, когда он не смог выполнить ни одно из условий из запроса клиента.
413 Request Entity Too Large Код состояния ошибки HTTP клиента  413: объект запроса слишком велик
А такой код ошибки клиента можно увидеть в том случае, когда тело запроса слишком большое и сервер его получить не смог.
414 Request-url Too Long Код состояния ошибки HTTP клиента  414: URI запроса слишком длинный
Такой код ошибки клиента сервер выдаст в том случае, если URI запроса слишком длинный.
415 Unsupported Media Type Код состояния ошибки HTTP клиента  415: неподдерживаемый медиа тип
Сервер может выдать такой код состояния ошибки клиента в том случае, если не захочет работать с указанным типом данных (типы данных в HTTP) тем методом, который указан в запросе клиента
416 Requested Range Not Satisfiable Код состояния ошибки HTTP клиента  416: запрашиваемый диапазон не достижим
Данный код и ошибки клиента говорит нам о том, что диапазон фрагмента в поле заголовка Range указан неверно.
417 Expectation Failed Код состояния ошибки HTTP клиента  417: ожидаемое неприемлимо
Код состояния ошибки клиента 417 появится в том случае, если сервер не сможет удовлетворить значению, указанному в поле заголовка Expect.

Список кодов ошибок HTTP сервера

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

Код ошибки HTTP сервера Описание кода ошибки HTTP сервера
500 InternalServerError Код состояния ошибки HTTP сервера 500: внутренняя ошибка сервера
Если вы видите ошибку HTTP сервера с кодом 500, то знайте, что это может любая внутренняя ошибка HTTP сервера, которая не входит в рамки других ошибок, в том числе и ошибок, описанных в других классах.
501 NotImplemented Код состояния ошибки HTTP сервера  501: не реализовано
Если вы видите ошибку HTTP сервера с кодом 501, то это означает, что сервер не может выполнить HTTP сообщение, полученное от клиента, из-за ограниченного функционала. Ошибка сервера 501 может возникнуть из-за настроек сервера. Часто ошибка 501 возникает из-за того, что сервер не может распознать метод, указанный в запросе.
502 BadGateway Код состояния ошибки HTTP сервера  502: ошибка шлюза
Если вы видите ошибку HTTP сервера с кодом 502, то это означает, что HTTP сервер действует в качестве шлюза или прокси-сервера и при этом он получил недопустимый ответ от следующего в цепочке запросов сервера, к которому обращался при попытке выполнить запрос.
503 ServiceUnavailable Код состояния ошибки HTTP сервера  503: сервис недоступен
Если вы видите ошибку HTTP сервера с кодом 503, то это означает, что в настоящее время сервер недоступен из-за его перегрузки или он находится на техническом обслуживание. Если сервер знает о продолжительности задержки, то вместе с кодом ошибки 503, он может указать время в поле заголовка Retry-After.
504 GatewayTimeout Код состояния ошибки HTTP сервера  504: истекло время ожидания
Если вы видите ошибку HTTP сервера с кодом 504 возникает в том случае, когда HTTP сервер действует в роли прокси-сервера или шлюза (сервер Apache может выступать и в той и в другой роли) и не получил своевременного ответа от следующего сервера, к которому он обращался, чтобы выполнить запрос.
505 HTTP VersionNotSupported Код состояния ошибки HTTP сервера  505: сервис недоступен
Если вы видите ошибку HTTP сервера с кодом 505, то это означает, что сервер не поддерживает или отказывается поддерживать версию HTTP протокола (кстати, версия — это очень важный параметр HTTP протокола, который определяет, как будет установлено HTTP соединение), указанную в запросе.

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

Код 200 — это… Что такое Код 200?

301

Moved Permanently (русск. Перемещёно окончательно)
Появился в HTTP/1.0.

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоит забывать, что некоторые клиенты ошибочно меняют метод POST на GET после перехода на другой адрес.

Ответ может кэшироваться.

Если код состояния 301 получен после запроса GET или HEAD, то клиент должен запросить пользователя перед адресацией.

302

Found (русск. Найдено)
Введено в HTTP/1.0.

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые клиенты.

Код является примером того, как практика не соответствует стандартам. Спецификация HTTP/1.0 требовала от клиента осуществления временной переадресации («Moved temporarly» в оригинале), но популярные браузеры использовали 303 See other. Поэтому спецификация HTTP/1.1 (RFC 2068) добавила коды состояний 303 и 307, пытаясь избавиться от неоднозначности. Тем не менее, большинство веб-приложений по прежнему используют код 302, как если бы он был кодом 303.

303

See Other (русск. Смотреть другое)
Введено в HTTP/1.1.

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304

Not Modified (русск. Не изменено)
Появился в HTTP/1.0.

Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305

Use Proxy (русск. Использовать прокси)
Введено в HTTP/1.1.

Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).

306

Упомянуто в RFC 2616 (обновление HTTP/1.1).

Использовалось раньше. В настоящий момент зарезервировано.

307


Temporary Redirect (русск. Временное перенаправление) Введено в RFC 2616 (обновление HTTP/1.1).

Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.

4xx: Client Error

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Для облегчения запоминания значений кодов существуют приёмы иллюстративной мнемотехники (например, для диапазона 400 по 417 [1])

400

Bad Request (русск. Плохой запрос)
Появился в HTTP/1.0.

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

401

Unauthorized (русск. Неавторизован)
Появился в HTTP/1.0.

Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.

402

Payment Required (русск. Необходима оплата )
Зарезервирован начиная с HTTP/1.1.

Предполагается использовать в будущем. В настоящий момент не используется.

403

Сервер вернул ошибку 403 при попытке просмотра директории cgi-bin, доступ к которой был запрещён

Forbidden (русск. Запрещено)
Появился в HTTP/1.0.

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

Сообщение 403 может возвращаться, если хозяин сайта по каким-то соображениям решил закрыть от пользователей часть информации. Кроме того, если веб-сервер не имеет прав доступа к запрошенному документу, он также вернёт код 403. Простая ситуация, когда страница может на самом деле не существовать, но сервер выдаст ошибку 403 (запрещено), а не 404 (не найдено): страница находится в директории foo, доступ к которой был запрещён веб-серверу — таким образом веб-сервер не может «знать», есть в этой директории такая страница, или нет.

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

404

Попытка запросить документ /fgsfds в Википедии приводит к ошибке 404. Тем не менее, программное обеспечение Википедии перенаправляет нас на соответствующую статью, которая могла бы существовать.

Not Found (русск. Не найдено)
Появился в HTTP/1.0.

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

Ссылки

405

Method Not Allowed (русск. Метод не поддерживается)
Появился в HTTP/1.1.

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

406

Not Acceptable (русск. Не приемлемо)
Появился в HTTP/1.1.

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

407

Proxy Authentication Required (русск. Необходима авторизация прокси)
Появился в HTTP/1.1.

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

408

Request Timeout (русск. Время ожидания истекло)
Появился в HTTP/1.1,

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

409

Conflict (русск. Конфликт)
Появился в HTTP/1.1.

Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410

Gone (русск. Удалён)
Появился в HTTP/1.1.

Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411

Length Required (русск. Необходима длина)
Появился в HTTP/1.1.

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

412

Precondition Failed (русск. Условие «ложно»)
Появился в HTTP/1.1.

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413

Request Entity Too Large (русск. Запрашиваемые данные слишком большие)
Появился в HTTP/1.1.

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

414

Request-URI Too Long (русск. Запрашиваемый URI слишком длинный)
Появился в HTTP/1.1.

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

415

Unsupported Media Type (русск. Неподдерживаемый тип данных)
Появился в HTTP/1.1.

По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416

Requested Range Not Satisfiable (русск. Запрашиваемый диапазон не достижим)
Введено в RFC 2616 (обновление HTTP/1.1).

В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417

Expectation Failed (русск. Ожидаемое ошибочно)
Введено в RFC 2616 (обновление HTTP/1.1).

По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422

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

423

Locked (русск. Заблокировано)
Введено в

424

Failed Dependency (русск. Невыполненная зависимость)
Введено в 424.

426

Upgrade Required (русск. Необходимо обновление)
Введено в RFC 2817 для возможности перехода к

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

5xx: Server Error

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500

Internal Server Error (русск. Внутренняя ошибка сервера)
Появился в HTTP/1.0.

Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501

Not Implemented (русск. Не реализовано)
Появился в HTTP/1.0.

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

502

Bad Gateway (русск. Плохой шлюз)
Появился в HTTP/1.0.

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

503

Service Unavailable (русск. Сервис недоступен)
Появился в HTTP/1.0.

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

504

Gateway Timeout (русск. Шлюз не отвечает)
Появился в HTTP/1.1.

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

505

HTTP Version Not Supported (русск. Версия HTTP не поддерживается)
Появился в HTTP/1.1.

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506

Variant Also Negotiates (русск. Вариант тоже согласован)
Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

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

507

Insufficient Storage (русск. Закончилось место)
Введено в

510

Not Extended (русск. Не расширено)
Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.

Примечания

См. также

Ссылки

Ошибка 200 — это… Что такое Ошибка 200?

301

Moved Permanently (русск. Перемещёно окончательно)
Появился в HTTP/1.0.

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоит забывать, что некоторые клиенты ошибочно меняют метод POST на GET после перехода на другой адрес.

Ответ может кэшироваться.

Если код состояния 301 получен после запроса GET или HEAD, то клиент должен запросить пользователя перед адресацией.

302

Found (русск. Найдено)
Введено в HTTP/1.0.

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые клиенты.

Код является примером того, как практика не соответствует стандартам. Спецификация HTTP/1.0 требовала от клиента осуществления временной переадресации («Moved temporarly» в оригинале), но популярные браузеры использовали 303 See other. Поэтому спецификация HTTP/1.1 (RFC 2068) добавила коды состояний 303 и 307, пытаясь избавиться от неоднозначности. Тем не менее, большинство веб-приложений по прежнему используют код 302, как если бы он был кодом 303.

303

See Other (русск. Смотреть другое)
Введено в HTTP/1.1.

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304

Not Modified (русск. Не изменено)
Появился в HTTP/1.0.

Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305

Use Proxy (русск. Использовать прокси)
Введено в HTTP/1.1.

Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).

306

Упомянуто в RFC 2616 (обновление HTTP/1.1).

Использовалось раньше. В настоящий момент зарезервировано.

307


Temporary Redirect (русск. Временное перенаправление) Введено в RFC 2616 (обновление HTTP/1.1).

Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.

4xx: Client Error

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Для облегчения запоминания значений кодов существуют приёмы иллюстративной мнемотехники (например, для диапазона 400 по 417 [1])

400

Bad Request (русск. Плохой запрос)
Появился в HTTP/1.0.

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

401

Unauthorized (русск. Неавторизован)
Появился в HTTP/1.0.

Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.

402

Payment Required (русск. Необходима оплата )
Зарезервирован начиная с HTTP/1.1.

Предполагается использовать в будущем. В настоящий момент не используется.

403

Сервер вернул ошибку 403 при попытке просмотра директории cgi-bin, доступ к которой был запрещён

Forbidden (русск. Запрещено)
Появился в HTTP/1.0.

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

Сообщение 403 может возвращаться, если хозяин сайта по каким-то соображениям решил закрыть от пользователей часть информации. Кроме того, если веб-сервер не имеет прав доступа к запрошенному документу, он также вернёт код 403. Простая ситуация, когда страница может на самом деле не существовать, но сервер выдаст ошибку 403 (запрещено), а не 404 (не найдено): страница находится в директории foo, доступ к которой был запрещён веб-серверу — таким образом веб-сервер не может «знать», есть в этой директории такая страница, или нет.

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

404

Попытка запросить документ /fgsfds в Википедии приводит к ошибке 404. Тем не менее, программное обеспечение Википедии перенаправляет нас на соответствующую статью, которая могла бы существовать.

Not Found (русск. Не найдено)
Появился в HTTP/1.0.

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

Ссылки

405

Method Not Allowed (русск. Метод не поддерживается)
Появился в HTTP/1.1.

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

406

Not Acceptable (русск. Не приемлемо)
Появился в HTTP/1.1.

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

407

Proxy Authentication Required (русск. Необходима авторизация прокси)
Появился в HTTP/1.1.

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

408

Request Timeout (русск. Время ожидания истекло)
Появился в HTTP/1.1,

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

409

Conflict (русск. Конфликт)
Появился в HTTP/1.1.

Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410

Gone (русск. Удалён)
Появился в HTTP/1.1.

Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411

Length Required (русск. Необходима длина)
Появился в HTTP/1.1.

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

412

Precondition Failed (русск. Условие «ложно»)
Появился в HTTP/1.1.

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413

Request Entity Too Large (русск. Запрашиваемые данные слишком большие)
Появился в HTTP/1.1.

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

414

Request-URI Too Long (русск. Запрашиваемый URI слишком длинный)
Появился в HTTP/1.1.

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

415

Unsupported Media Type (русск. Неподдерживаемый тип данных)
Появился в HTTP/1.1.

По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416

Requested Range Not Satisfiable (русск. Запрашиваемый диапазон не достижим)
Введено в RFC 2616 (обновление HTTP/1.1).

В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417

Expectation Failed (русск. Ожидаемое ошибочно)
Введено в RFC 2616 (обновление HTTP/1.1).

По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422

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

423

Locked (русск. Заблокировано)
Введено в

424

Failed Dependency (русск. Невыполненная зависимость)
Введено в 424.

426

Upgrade Required (русск. Необходимо обновление)
Введено в RFC 2817 для возможности перехода к

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

5xx: Server Error

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500

Internal Server Error (русск. Внутренняя ошибка сервера)
Появился в HTTP/1.0.

Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501

Not Implemented (русск. Не реализовано)
Появился в HTTP/1.0.

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

502

Bad Gateway (русск. Плохой шлюз)
Появился в HTTP/1.0.

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

503

Service Unavailable (русск. Сервис недоступен)
Появился в HTTP/1.0.

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

504

Gateway Timeout (русск. Шлюз не отвечает)
Появился в HTTP/1.1.

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

505

HTTP Version Not Supported (русск. Версия HTTP не поддерживается)
Появился в HTTP/1.1.

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506

Variant Also Negotiates (русск. Вариант тоже согласован)
Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

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

507

Insufficient Storage (русск. Закончилось место)
Введено в

510

Not Extended (русск. Не расширено)
Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.

Примечания

См. также

Ссылки

200 OK — Веб-технологии для разработчиков

HTTP 200 OK код ответа состояния успеха указывает, что запрос выполнен успешно. По умолчанию ответ 200 кэшируется.

Значение успеха зависит от метода HTTP-запроса:

  • GET : ресурс был получен и передан в теле сообщения.
  • HEAD : заголовки объекта находятся в теле сообщения.
  • POST : ресурс, описывающий результат действия, передается в теле сообщения.
  • TRACE : тело сообщения содержит сообщение запроса, полученное сервером.

Успешный результат PUT или DELETE часто не 200 OK , а 204 Нет содержимого (или 201 Создается , когда ресурс загружен для первый раз).

Статус

 200 ОК 

Технические характеристики

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

Таблица совместимости на этой странице создана на основе структурированных данных.Если вы хотите внести свой вклад в данные, посетите https://github.com/mdn/browser-compat-data и отправьте нам запрос на перенос.

Обновите данные о совместимости на GitHub

Desktop Mobile
Chrome Edge Firefox Internet Explorer Opera Safari Android webview Chrome для Android Firefox для Android Opera для Android Safari на iOS Samsung Internet
200 Chrome
Полная поддержка

Да
Кромка
Полная поддержка

12
Firefox
Полная поддержка

Есть
IE
Полная поддержка

Да
Opera
Полная поддержка

Да
Safari
Полная поддержка

Да
WebView Android
Полная поддержка

Да
Chrome Android
Полная поддержка

Да
Firefox Android
Полная поддержка

Да
Opera Android
Полная поддержка

Да
Safari iOS
Полная поддержка

Да
Samsung Интернет Android
Полная поддержка

Да

Обозначения


Полная поддержка

Полная поддержка

См. Также

Реестр кодов состояния протокола передачи гипертекста (HTTP)

Вариант

100 Продолжить [RFC7231, раздел 6.2.1]
101 Протоколы коммутации [RFC7231, раздел 6.2.2]
102 Обработка [RFC2518]
103 Ранние подсказки [RFC8297]
104-199 Не назначено
200 ОК [RFC7231, раздел 6.3.1]
201 Создано [RFC7231, раздел 6.3.2]
202 Принято [RFC7231, раздел 6.3.3]
203 Неавторизованная информация [RFC7231, раздел 6.3.4]
204 Нет содержимого [RFC7231, раздел 6.3.5]
205 Сбросить содержимое [RFC7231, раздел 6.3.6]
206 Частичное содержимое [RFC7233, раздел 4.1]
207 Мульти-статус [RFC4918]
208 Уже сообщено [RFC5842]
209-225 Не назначено
226 IM Б / У [RFC3229]
227-299 Не назначено
300 Множественный выбор [RFC7231, раздел 6.4.1]
301 Перемещено навсегда [RFC7231, раздел 6.4.2]
302 Найдено [RFC7231, раздел 6.4.3]
303 См. Другие [RFC7231, раздел 6.4.4]
304 Без изменений [RFC7232, раздел 4.1]
305 Использовать прокси [RFC7231, раздел 6.4.5]
306 (Не используется) [RFC7231, раздел 6.4.6]
307 Временное перенаправление [RFC7231, раздел 6.4.7]
308 Постоянное перенаправление [RFC7538]
309-399 Не назначено
400 Неверный запрос [RFC7231, раздел 6.5.1]
401 Несанкционированный [RFC7235, раздел 3.1]
402 Требуется оплата [RFC7231, раздел 6.5.2]
403 Запрещено [RFC7231, раздел 6.5.3]
404 Не найдено [RFC7231, раздел 6.5.4]
405 Метод запрещен [RFC7231, раздел 6.5.5]
406 Неприемлемо [RFC7231, раздел 6.5.6]
407 Требуется проверка подлинности прокси-сервера [RFC7235, раздел 3.2]
408 Тайм-аут запроса [RFC7231, раздел 6.5,7]
409 Конфликт [RFC7231, раздел 6.5.8]
410 Ушел [RFC7231, раздел 6.5.9]
411 Требуемая длина [RFC7231, раздел 6.5.10]
412 Ошибка предварительного условия [RFC7232, раздел 4.2] [RFC8144, раздел 3.2]
413 Слишком большая полезная нагрузка [RFC7231, раздел 6.5.11]
414 URI слишком длинный [RFC7231, раздел 6.5.12]
415 Неподдерживаемый тип носителя [RFC7231, раздел 6.5.13] [RFC7694, раздел 3]
416 Диапазон не соответствует требованиям [RFC7233, раздел 4.4]
417 Ожидание не выполнено [RFC7231, раздел 6.5.14]
418-420 Не назначено
421 Неверный запрос [RFC7540, раздел 9.1.2]
422 Необработанная сущность [RFC4918]
423 Заблокировано [RFC4918]
424 Неудачная зависимость [RFC4918]
425 Слишком рано [RFC8470]
426 Требуется обновление [RFC7231, раздел 6.5.15]
427 Не назначено
428 Требуется предварительное условие [RFC6585]
429 Слишком много запросов [RFC6585]
430 Не назначено
431 Слишком большие поля заголовка запроса [RFC6585]
432-450 Не назначено
451 Недоступно по юридическим причинам [RFC7725]
452-499 Не назначено
500 Внутренняя ошибка сервера [RFC7231, раздел 6.6.1]
501 Не реализовано [RFC7231, раздел 6.6.2]
502 Плохой шлюз [RFC7231, раздел 6.6.3]
503 Служба недоступна [RFC7231, раздел 6.6.4]
504 Тайм-аут шлюза [RFC7231, раздел 6.6.5]
505 Версия HTTP не поддерживается [RFC7231, раздел 6.6.6]
506 также обсуждает [RFC2295]
507 Недостаточно памяти [RFC4918]
508 Обнаружена петля [RFC5842]
509 Не назначено
510 Не расширенный [RFC2774]
511 Требуется сетевая аутентификация [RFC6585]
512-599 Не назначено

Коды статуса HTTP — ascii-code.com

Ниже приведен список кодов ответа для HTTP, возвращаемых серверами в Интернете. Большинство этих кодов состояния указаны в RFC 2616, а некоторые —
нестандартные коды статуса, которые также используются в Интернете. Коды помогают определить причину
проблема, когда веб-страница или другой ресурс не загружается должным образом. Код ответа от 1XX до 5XX.

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

Коды состояния HTTP в 1xx обычно носят информационный характер.

  • 100 Продолжить
  • 101 Протоколы коммутации
  • 102 Обработка
  • 103 КПП
  • 122 Слишком длинный URI запроса

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

Коды состояния в диапазоне 2xx указывают на то, что транзакция была получена, понята, принята и обработана успешно.

  • 200 ОК
  • 201 Создано
  • 202 Принято
  • 203 Неавторизованная информация (начиная с HTTP / 1.1)
  • 204 Нет содержимого
  • 205 Сбросить содержимое
  • 206 Частичное содержимое
  • 207 Мульти-статус (WebDAV) (RFC 4918)
  • 226 IM Используется (RFC 3229)

3xx Ответы на перенаправление

Коды состояния HTTP в диапазоне 3xx относятся к перенаправлению. Клиент должен предпринять дополнительные действия для выполнения запроса.

  • 300 Множественный выбор
  • 301 Постоянно перемещен
  • 302 Найдено
  • 303 См. Другое (начиная с HTTP / 1.1)
  • 304 Без изменений
  • 305 Использовать прокси (начиная с HTTP / 1.1)
  • 306 Прокси-сервер коммутатора
  • 307 Временное перенаправление (с HTTP / 1.1)
  • 308 Неполное резюме

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

Коды состояния HTTP в диапазоне 4xx указывают на то, что с запросом возникла проблема.

  • 400 неверный запрос
  • 401 Неавторизованный
  • 402 Требуется оплата
  • 403 Запрещено
  • 404 Не найдено
  • 405 Метод запрещен
  • 406 Неприемлемо
  • 407 Требуется проверка подлинности прокси
  • 408 Тайм-аут запроса
  • 409 Конфликт
  • 410 Исчез
  • 411 Требуемая длина
  • 412 Ошибка предварительного условия
  • 413 Запрос слишком большой объект
  • 414 Слишком длинный URI запроса
  • 415 Неподдерживаемый тип носителя
  • 416 Запрошенный диапазон Не выполняется
  • 417 Неудачное ожидание
  • 418 Я чайник (RFC 2324)
  • 422 Необработанный объект (WebDAV) (RFC 4918)
  • 423 Заблокировано (WebDAV) (RFC 4918)
  • 424 Неудачная зависимость (WebDAV) (RFC 4918)
  • 425 Неупорядоченная коллекция (RFC 3648)
  • 426 Требуется обновление (RFC 2817)
  • 428 Требуются предварительные условия
  • 429 Слишком много запросов
  • 431 Слишком большие поля заголовка запроса
  • 444 Нет ответа
  • 449 Повторить попытку с
  • 450 Заблокировано родительским контролем Windows
  • 499 Запрос клиента закрыт

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

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

  • 500 Внутренняя ошибка сервера
  • 501 Не реализовано
  • 502 Плохой шлюз
  • 503 Служба недоступна
  • 504 Тайм-аут шлюза
  • 505 Версия HTTP не поддерживается
  • 506 Вариант также согласовывается (RFC 2295)
  • 507 Недостаточно места для хранения (WebDAV) (RFC 4918)
  • 509 Превышен предел пропускной способности (Apache bw / ограниченное расширение)
  • 510 Не расширенный (RFC 2774)
  • 511 Требуется сетевая аутентификация
  • 598 (неофициальное соглашение) ошибка тайм-аута сетевого чтения
  • 599 (неофициальное соглашение) ошибка тайм-аута сетевого подключения

Http Durum Kodları ve Anlamları (коды статуса Http)

Последнее обновление 17 Aralık 2019

Http Durum Kodları, İstemci bir sunucu içeriğine HTTP kullanarak ulaşmaya çalıştınirduntınındıkı.Bazı durumlarda HTTP durum kodu (код состояния HTTP) istemcinin tarayıcısında da gösterilebilir.

Http Durum Kodları

Http Durum Kodlarına örnek vermemiz gerekirse en yaygın olan durum kodları 200, 301, 302, 404 ve 500’dür. Yaygın olarak kullanılan kodlar aşağıdaki kategorize dilmiş бир şekilde sırasıyla tablolarda verilmiştir.

1xx: Bilgi

Mesaj Açıklama
100 Продолжить Devam
101 Протоколы переключения Anahtarlama Protokolü
102 Обработка
102

122 Слишком длинный URI запроса İstekte bulunduğunuz adres çok uzun

2xx: Başarı

900C58 9 İçerik Yoker

900c58 9 Сбросить содержимое

me

Mesaj Açıklama
200 OKam

Oluşturuldu
202 Принято Onaylandı
203 Неавторизованная информация Yetersiz Bilgi
204 Нет содержимого İçerik Yoker
206 Частично Контент Kısmi İçerik
207 Мульти-статус Çok-Statü
210 Различный контент Farklı İçerik
226 Используемый IM (RFC 3229)
900ç99 307 olarak
Mesaj Açıklama
300 Множественный выбор ok Seçenek
301 Постоянно перемещен Kalıcı Olarak Taşındı
302çındı 302çındı

Diğerlerine Bak
304 Не изменено Nitelenemedi
305 Использовать прокси Прокси Kullan2
306 Прокси-сервер Switch Proxy'e geçildi
308 Неполное резюме 90 102

4xx: Tarayıcı Hatası

Оплата

    is 9099 Ödeme Gerekli

406 Edmeyen

Acceptable

407 Proxy Authentication Required

900 424 Ошибка метода

900

Mesaj Açıklama
400 Плохой запрос Kötü İstek
401 Неавторизованный
403 Запрещено Yasaklandı
404 Не найдено Sayfa Bulunamadı
405 Метод запрещен İzin verilmeyen
Proxy Sunucuda login olmak gerekli
408 Request Timeout İstek zaman aşamına uğradı
409 Conflict 2 (Hatlar) Çakııştı, akıştı, akıştı, akıştı,
411 Лен gth Требуется
412 Ошибка предварительного условия
413 Слишком большой объект запроса
414 URI запроса слишком длинный
415 Неподдерживаемый тип носителя
416 Запрошено 416
417 Неудачное ожидание
418 Я чайник (RFC 2324)
422 Необработанный объект
423 Заблокирован
425 Неупорядоченная коллекция (RFC 3648)
Требуется обновление 426 (RFC 2817)
428 Требуется предварительное условие
429 Слишком много запросов
431 Поля заголовка запроса 900 слишком большие 9010 MDN: Заголовок Sunucunun alanları çok büyük olduğu için isteği işlem ek istemediğini gösterir.İstek, заголовок alanlarının boyunuzu küçülttükten sonra yeniden denenebilir.

Toplam istek header alanı sayısı çok büyük oldu bunda veya tek bir başlık alanı çok büyük olduunda kullanılan durumdur.

444 Нет ответа
449 Повторить попытку с
450 Заблокировано родительским контролем Windows
499 Клиент закрытый запрос

5xx:

Hatas56

Mesaj Açıklama 500 Внутренняя ошибка сервера 501 Не реализовано Uygulanmamış 502 Плохая служба шлюза

HECSID

Geçidiz Yok 504 Тайм-аут шлюза 505 Версия HTTP не поддерживается 506 Вариант также согласовывается (RFC 2295) 507 Недостаточно хранилища 509 Превышен предел пропускной способности Apache чб / ограниченные экстенси on) 510 Не расширен (RFC 2774) 511 Требуется сетевая аутентификация 598 (неофициальное соглашение) ошибка тайм-аута сетевого чтения 599 (неформальное соглашение) таймаут сетевого подключения ошибка

İ İlgilenebileceğiniz Bazı Kaynaklar


📝 Lütfen olumlu-olumsuz tüm görüşlerinizi bana yorum iada mey.

🔗 Sosyal medya kanallarından makaleyi paylaşarak destek olursanız çok sevinirim.

👋 Bir sonraki makalede görüşmek dileğiyle.

httpstat.us

Это очень простой сервис для генерации различных кодов HTTP.

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

Просто добавьте код статуса, который вы хотите, в URL-адрес, например:
httpstat.us/200

Мы вернем такой ответ:

HTTP / 1.1 {код статуса} {описание статуса}
Тип содержимого: текст / простой или приложение / json
Content-Length: {something}
{любые персонализированные заголовки ответов}

{код статуса} {описание статуса}
{список любых добавленных нами пользовательских заголовков ответов}

Чтобы получить ответ JSON, вам необходимо убедиться, что заголовок Accept содержит «application / json». Затем мы закодируем ответ в формате JSON и соответствующим образом отправим заголовок Content-Type.

Если вам нужна задержка ответа, добавьте строку запроса сна (время в мс, максимум 5 минут *), например:
httpstat.нас / 200? сна = 5000

* При использовании размещенного экземпляра тайм-аут фактически составляет 230 секунд, что является максимальным таймаутом, разрешенным веб-приложением Azure (см. Эту публикацию в ветке). Если вы разместите его самостоятельно в IIS / IIS Express, у вас не будет этого ограничения.

Вот все коды, которые мы поддерживаем (и любые особые примечания):

100
Продолжить
101
Протоколы переключения
102
Обработка
103
Ранние подсказки
200
ОК
201
Создано
202
Принято
203
Неавторитетная информация
204
Нет содержимого
205
Сбросить содержимое
206
Частичное содержимое
300
Множественный выбор
301
Постоянно перемещен
302
Найдено
303
См. Другие
304
Не модифицируется
305
Использовать прокси
306
Не используется
307
Временное перенаправление
308
Постоянное перенаправление
400
Плохой запрос
401
Несанкционированный
402
Требуется оплата
403
Запрещено
404
Не найдено
405
Недопустимый метод
406
Неприемлемо
407
Требуется проверка подлинности прокси
408
Время ожидания запроса
409
Конфликт
410
Исчез
411
Требуемая длина
412
Ошибка предварительного условия
413
Слишком большой объект запроса
414
Слишком длинный URI запроса
415
Неподдерживаемый тип носителя
416
Запрошенный диапазон не соответствует требованиям
417
Ожидание не удалось
418
Я чайник
421
Неверный запрос
422
Непроцессная сущность
423
Закрытый
425
Слишком рано
426
Требуется обновление
428
Требуется предварительное условие
429
Слишком много запросов
431
Слишком большие поля заголовка запроса
451
Недоступно по юридическим причинам
500
Внутренняя ошибка сервера
501
Не реализовано
502
Плохой шлюз
503
Служба недоступна
504
Тайм-аут шлюза
505
Версия HTTP не поддерживается
506
Вариант также обсуждает
507
Недостаточно памяти
511
Требуется сетевая аутентификация
520
Веб-сервер возвращает неизвестную ошибку
522
Превышено время ожидания соединения
524
Истекло время ожидания

Если вам нужно включить CORS, просто добавьте / cors в конце URL-адреса.Например: httpstat.us/200/cors.

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

Наслаждайтесь!

Создан
Аарон Пауэлл
а также
Татхам Одди
, размещенный на
Веб-приложение Azure
.

Мы не собираем и не храним никаких данных о ваших запросах.

Коды состояния HTTP

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

Коды состояния ответа разделены на 5 классов: информационный , успешный , перенаправление , ошибка клиента и ошибка сервера .

КОДЫ HTTP - 100-101

(Информационный класс)

100 - Продолжить

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

101 - Протоколы коммутации

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


КОДЫ HTTP 200-206

(класс успеха)

200 - ОК

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

201 - Создано

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

202 - Принято

Запрос принят в обработку, но еще не обработан.

203 - Неавторизованная информация

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

204 - Без содержания

Запрос был успешным, но не требует возврата тела объекта.

205 - сбросить содержимое

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

206 - Частичное содержимое

Частичный запрос GET был успешным.


КОДЫ HTTP 300-307

(класс перенаправления)

300 - множественный выбор

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

301 - Постоянно перемещен

Ресурс навсегда переместился на другой URI.

302 - Найдено

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

303 - См. Другие

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

304 - без изменений

Ресурс не изменялся с момента последнего запроса.

305 - Использовать прокси

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

306 - больше не используется

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

307 - временное перенаправление

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


КОДЫ HTTP 400-417

(класс ошибки клиента)

400 - неверный запрос

Синтаксис запроса не был понят сервером.

401 - Не авторизован

Запрос требует аутентификации пользователя

402 - Требуется оплата

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

403 - Запрещено

Сервер отказался выполнить запрос.

404 - Не найдено

Документ / файл, запрошенный клиентом, не найден.

405 - Метод запрещен

Метод, указанный в строке запроса, не разрешен для указанного ресурса.

406 - Не допускается

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

407 - Требуется проверка подлинности прокси

Запрос сначала требует аутентификации с помощью прокси.

408 - Тайм-аут запроса

Клиенту не удалось отправить запрос в срок, разрешенный сервером.

409 - Конфликт

Запрос был неудачным из-за конфликта в состоянии ресурса.

410 - Исчез

Запрошенный ресурс больше недоступен, и адрес пересылки недоступен.

411 - Требуемая длина

Сервер не примет запрос без действительного поля заголовка Content-Length.

412 - Ошибка предварительного условия

Предварительное условие, указанное в одном или нескольких полях заголовка запроса, вернуло false.

413 - Слишком большой объект запроса

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

414 - Слишком длинный URI запроса

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

415 - Неподдерживаемый тип носителя

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

416 - Запрошенный диапазон не выполняется

Запрос включал поле заголовка запроса Range, и ни одно из значений спецификатора диапазона в этом поле не перекрывает текущий экстент выбранного ресурса, а также запрос не включает поле заголовка запроса If-Range.

417 - Ожидание не выполнено

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


КОДЫ HTTP 500-505

(класс ошибки сервера)

500 - Внутренняя ошибка сервера

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

501 - Не реализовано

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

502 - Плохой шлюз

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

503 - Служба недоступна

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