Continue
Сервер получил заголовки, и клиент может отправлять тело запроса. Используется с "Expect: 100-continue" перед большими загрузками.
RFC 9110Коды состояния HTTP
Ищите по номеру или названию либо фильтруйте по классу. У каждого кода есть ссылка на спецификацию.
1xx Информационные
Запрос получен, обработка продолжается. В коде приложений встречается редко.
Switching Protocols
Сервер соглашается сменить протокол по просьбе клиента, например с HTTP/1.1 на WebSocket.
RFC 9110Processing
WebDAV: сервер принял запрос и ещё обрабатывает его, клиенту не стоит обрывать соединение по тайм-ауту.
RFC 2518Early Hints
Заранее отправляет заголовки Link, чтобы браузер предзагрузил CSS или шрифты, пока сервер готовит основной ответ.
RFC 82972xx Успешные
Запрос получен, понят и принят.
Non-Authoritative Information
Успешно, но ответ изменён преобразующим прокси, поэтому он не полностью совпадает с ответом источника.
RFC 9110No Content
Успешно, тела для возврата нет. Часто для DELETE или сохранения формы без перезагрузки страницы.
RFC 9110Partial Content
Возвращается только часть ресурса по заголовку Range. Используется для докачки и перемотки видео.
RFC 91103xx Перенаправления
Для завершения запроса нужно дополнительное действие, обычно переход по другому URL.
Multiple Choices
Есть несколько представлений (например, языков или форматов), клиент должен выбрать одно.
RFC 9110Moved Permanently
Ресурс навсегда переехал на новый URL из заголовка Location. Поисковики передают позиции новому адресу.
RFC 9110Found
Ресурс временно находится по другому URL. Клиенты продолжают использовать исходный; браузеры могут превратить POST в GET.
RFC 9110See Other
Результат доступен по другому URL через GET. Используется после POST формы, чтобы избежать повторной отправки (Post/Redirect/Get).
RFC 9110Not Modified
Копия в кэше ещё актуальна (совпал If-None-Match или If-Modified-Since), поэтому тело не отправляется.
RFC 91104xx Ошибки клиента
Запрос ошибочен: неверный синтаксис, нет аутентификации, нет прав или ресурс не существует.
Bad Request
Сервер не может обработать некорректный запрос: неверный синтаксис, сломанный JSON или неправильные параметры.
RFC 9110Unauthorized
Аутентификации нет или она недействительна. В ответе есть заголовок WWW-Authenticate со способом входа.
RFC 9110Payment Required
Зарезервирован для будущих систем цифровых платежей; некоторые API используют его, когда нужно оплатить подписку или квоту.
RFC 9110Forbidden
Сервер знает, кто вы, но отказывает из-за отсутствия прав. Повторный вход не поможет.
RFC 9110Method Not Allowed
HTTP-метод не поддерживается для этого URL, например POST к ресурсу только для чтения. Заголовок Allow перечисляет допустимые методы.
RFC 9110Not Acceptable
Сервер не может сформировать ответ, подходящий под заголовки Accept (тип, язык или кодировка).
RFC 9110Proxy Authentication Required
Как 401, но клиент сначала должен пройти аутентификацию на прокси.
RFC 9110Conflict
Запрос конфликтует с текущим состоянием, например конфликт правок или дубликат уникального ключа.
RFC 9110Precondition Failed
Условный заголовок вроде If-Match не совпал; часто используется, чтобы не перезаписать чужие изменения.
RFC 9110URI Too Long
URL длиннее, чем принимает сервер, часто из-за слишком большого объёма данных в строке запроса GET.
RFC 9110Unsupported Media Type
Формат тела (Content-Type) не поддерживается, например XML в API, принимающее только JSON.
RFC 9110I'm a teapot
Первоапрельская шутка из протокола управления кофейниками: чайник не умеет варить кофе. Некоторые сайты используют его как пасхалку.
RFC 2324Misdirected Request
Запрос попал на сервер, который не может отвечать за этот хост, например когда повторно используемое соединение HTTP/2 ведёт не к тому источнику.
RFC 9110Unprocessable Content
Синтаксис верный, но содержимое некорректно, например не прошло валидацию (раньше "Unprocessable Entity").
RFC 9110Failed Dependency
WebDAV: запрос не выполнен, потому что зависел от другого, завершившегося ошибкой.
RFC 4918Too Early
Сервер не будет обрабатывать запрос, который может быть воспроизведён повторно, например early data в TLS 1.3.
RFC 8470Precondition Required
Сервер требует условных запросов (If-Match), чтобы избежать потери обновлений.
RFC 6585Too Many Requests
Клиент отправил слишком много запросов за отведённое время (rate limiting). Retry-After подскажет, когда повторить.
RFC 6585Request Header Fields Too Large
Заголовки слишком велики в сумме или по отдельности, часто из-за раздутых cookie.
RFC 6585Unavailable For Legal Reasons
Ресурс заблокирован по юридическим причинам, например цензура или решение суда. Число отсылает к роману «451 градус по Фаренгейту».
RFC 77255xx Ошибки сервера
Запрос выглядел корректно, но сервер не смог его обработать.
Internal Server Error
Общая ошибка: на сервере произошло что-то непредвиденное. Проверьте логи сервера.
RFC 9110Bad Gateway
Шлюз или прокси получил некорректный ответ от вышестоящего сервера, например когда упало приложение за Nginx.
RFC 9110Service Unavailable
Сервер временно не может обрабатывать запросы из-за перегрузки или обслуживания. Retry-After может указать, когда вернуться.
RFC 9110Variant Also Negotiates
Неверно настроено согласование содержимого: выбранный вариант сам пытается согласовывать дальше.
RFC 2295Insufficient Storage
WebDAV: сервер не может сохранить данные, нужные для выполнения запроса.
RFC 4918Network Authentication Required
Клиент должен сначала войти в сеть, обычно через страницу авторизации Wi-Fi в отеле или аэропорту.
RFC 6585Что такое коды состояния HTTP?
Каждый HTTP-ответ начинается с трёхзначного кода состояния, который сообщает клиенту, чем закончился запрос. Первая цифра задаёт класс: 1xx информационные, 2xx успешные, 3xx перенаправления, 4xx ошибки клиента и 5xx ошибки сервера. Браузеры, поисковики, кэши, API-клиенты и системы мониторинга действуют по этим кодам, поэтому важно выбирать правильный: 301 передаёт SEO-вес новому URL, а 302 нет, 503 просит роботов зайти позже, 429 просит API-клиентов снизить частоту запросов. Коды в основном определены в RFC 9110 (HTTP Semantics), часть в отдельных RFC.
Возможности
- • Все 61 код, зарегистрированный в IANA, от 100 до 511
- • Понятное объяснение смысла каждого кода и случаев применения
- • Мгновенный поиск по номеру, названию или слову и фильтры по классам
- • Прямые ссылки на раздел RFC, где определён каждый код
- • Цветовая маркировка классов и якоря #код для ссылок
Быстро и без сети
Весь справочник уже встроен в страницу, поэтому поиск работает мгновенно в браузере без запросов к серверу.
Справочник с поиском, без трекинга.
Как пользоваться: Коды состояния HTTP
- 1
Введите в поиск номер, например 404, название вроде "gateway" или слово вроде "redirect". Результаты обновляются по мере ввода.
- 2
Сужайте список кнопками классов (от 1xx до 5xx), например чтобы сразу просмотреть все ошибки клиента.
- 3
Читайте пояснение к каждому коду: что он значит, когда сервер должен его отправлять и как реагируют клиенты.
- 4
Откройте ссылку на RFC для точной спецификации или поделитесь кодом по якорю вида #429.
Практические примеры
Проектирование REST API
Возвращайте 201 Created с заголовком Location после POST, 204 No Content после DELETE, 400 при некорректном JSON, 422 при ошибках валидации и 409, если запрос конфликтует с текущим состоянием.
Перенос страниц без потери SEO
Используйте 301 или 308 для постоянного переноса, чтобы поисковики передали позиции, и 302 или 307 для временных редиректов, например A/B-тестов. 308 и 307 к тому же сохраняют метод POST.
Ошибки аутентификации
Отправляйте 401, если пользователь не вошёл или токен недействителен, и 403, если пользователь известен, но прав нет. Многие API отдают 404 вместо 403, чтобы скрыть существование ресурса.
Обслуживание и перегрузка
Во время работ возвращайте 503 с заголовком Retry-After, чтобы роботы сохранили позиции, а при превышении лимита запросов клиентом отдавайте 429 с Retry-After.
Частые вопросы
Чем отличаются 401 и 403?+
401 Unauthorized значит «кто вы?»: аутентификации нет или она не прошла. 403 Forbidden значит «я знаю, кто вы, но вам нельзя». Повторный вход исправит 401, но не 403.
301 или 302 для редиректа?+
Используйте 301 (или 308), если старый URL исчез навсегда, и 302 (или 307), если он вернётся. 302 при постоянном переносе может задержать индексацию нового URL.
Чем отличаются 502, 503 и 504?+
502 Bad Gateway: прокси получил некорректный ответ от вышестоящего сервера. 503 Service Unavailable: сервер перегружен или на обслуживании. 504 Gateway Timeout: вышестоящий сервер не ответил вовремя.
Можно ли при ошибке отдавать 200 с сообщением?+
Нет. Клиенты, кэши и мониторинг опираются на код состояния. 200 при сбое скрывает ошибки от инструментов и может привести к индексации страниц ошибок как «soft 404».