Полное руководство коды статуса HTTP


Оглавление (нажмите, чтобы открыть):

Что означают коды ответа сервера о состоянии страниц сайта

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

Некоторые типичные коды статуса HTTP:

  • 200 – сервер успешно обработал страницу;
  • 404 – запрашиваемая страница не существует;
  • 503 – информация временно недоступно

Ниже приводится полный список кодов состояния HTTP. Дополнительную информацию можно также получить на странице посвященной кодам протокола HTTP сайта W3C.

Коды http – 1xx (временный)

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

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

101 (Переключение протоколов)

От сервера запрошено переключение протоколов и сервер сообщает, что он выполнит запрос.

Коды http – 2xx (Успешно)

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

Код Описание

Сервер успешно обработал запрос. Как правило, это означает, что сервер предоставил необходимую страницу. Если это состояние относится к файлу robots.txt, это означает, что робот нашел его успешно.

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

Сервер принял запрос, но еще его не обработал.

203 (Ненадежная информация)

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

204 (Нет содержимого)

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

205 (Восстанавливать значение)

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

206 (Частичное содержание)

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

Коды http – 3xx (Перенаправлено)

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

Код Описание

300 (Много вариантов)

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

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

302 (Временно перемещено)

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

303 (Проверить другое место)

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

Запрашиваемая страница не была изменена с момента последнего запроса. Отправив этот ответ, сервер не возвращает тело страницы.

Необходимо настроить сервер на возвращение этого ответа (HTTP If-Modified-Since), если страница не изменилась с того времени, когда её последний раз запрашивал тот же агент. Это снижает нагрузку на пропускную способность и сервер.

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

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

307 (Временное перенаправление)

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

Коды http – 4xx (Ошибка запроса)

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

Код Описание

400 (Неверный запрос)

Сервер не распознает синтаксис запроса.

401 (Не авторизован)

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

403 (Доступ запрещен)

Сервер отклоняет запрос. Если поисковый робот получает этот код состояния HTTP при попытке индексации правильных страниц сайта (см. Ошибки индексирования на вкладке Сканирование в Инструментах Google для веб-мастеров), вероятно, сервер или хост блокирует доступ роботу googlebot возможность.

Сервер не может найти нужную страницу. Сервер часто возвращает этот код, например, в том случае, когда запрос относится к странице, которой не существует на сервере.

Если на сайте нет файла robots.txt и это состояние отображается на странице запрещенных URL в Инструментах Google для веб-мастеров, то это правильный статус. Однако, если на сайте есть файл robots.txt и, несмотря на это, отображается этот статус, файл robots.txt может иметь неверное имя или находиться в неправильном месте. (Файл должен находиться в корневом каталоге домена и носить имя robots.txt).

405 (Запрещенный метод)

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

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

Запрошенную страницу невозможно вернуть с требуемой характеристикой содержания.

407 (Требуется аутентификация на прокси-сервере)

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

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

Тайм-аут ожидания ответа от сервера.

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

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

411 (Обязательно указать длину)

Сервер не принимает запросы без правильного значения поля Content-Length (Содержание-Длина) в заголовке.

412 (Не соблюдены условия)

Сервер не соответствует одному из условий, размещенных в запросе.

413 (Слишком большой запрос)

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

414 (Запрашиваемый URI слишком большой)

Запрашиваемый URI (как правило, URL-адрес) слишком большой и сервер не может его обработать.

415 (Неподдерживаемый тип)

Запрос имеет не поддерживаемый формат.

416 (Не найден нужный диапазон)

Сервер возвращает этот код состояния, когда запрос касается диапазона, отсутствующего на сайте.

417 (Отказ ожидания)

Сервер не может выполнить требования, содержащиеся в поле Expect (Ждите), заголовка запроса.

Коды http– 5xx (Ошибка сервера)

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

Код Описание

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

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

501 (Функция не реализована)

Сервер не имеет функции, обеспечивающей исполнение запроса.

502 (Недопустимый шлюз)

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

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

Сервер в данный момент недоступен (перегружен или отключен в целях технического обслуживания). Как правило, это временное состояние.

504 (Тайм-аут шлюза)

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

505 (Неподдерживаемая версия HTTP)

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

Коды состояния HTTP и что они значат для SEO (перевод)

Коды состояния HTTP, такие как 404, 301 и 500, едва ли имеют значение для пользователей, но для оптимизаторов они невероятно важны. Мало того, что роботы поисковых систем (как Googlebot) используют их для определения здоровья сайта, коды состояния помогают узнать, что происходит между браузером и сервером. Некоторые из них указывает на ошибку, например, сигнализируют о том, что запрошенное содержимое не может быть найдено, в то время как другие просто выводят запрашиваемый материал. В этой статье мы пристальнее посмотрим на важнейшие коды HTTP заголовков и узнаем, что они означают для SEO.

Что такое коды состояния HTTP и почему вы их видите?

Код состояния HTTP – это сообщение, которое посылается сервером при отправке запроса с браузера, о том, может ли быть выполнен запрос или нет. Согласно официальной спецификации W3C, существуют десятки кодов состояния, со многими из которых вы вряд ли столкнетесь. А если столкнетесь, полный обзор возможных вариантов можно посмотреть на HTTPstatuses.com.

Чтобы понять эти коды, вам стоит знать, как браузер получает веб-страницу.

Добраться до веб-сайта пользователь может двумя способами – набрав URL сайта или введя запрос в строке поиска. После этого браузер посылает запрос на IP-адрес сайта, для получения соответствующей веб-страницы. Сервер отвечает браузеру, отправляя код состояния, встроенный в заголовок HTTP. Когда все нормально, код заголовка HTTP 200 отправляется обратно в браузер, вместе с запрошенным контентом.

Однако с запрашиваемым контентом или сервером что-то может быть не так. Например, не найдена страница (тогда возвращается код ошибки 404) или есть временная техническая проблема с сервером, в результате чего появляется код внутренней ошибки сервера 500. Эти коды статуса HTTP – важные инструменты для оценки состояния здоровья сайта и его сервера. Если сайт регулярно посылает неправильные коды заголовка HTTP в поисковую систему, его содержимое не индексируется, что, в свою очередь, вредит рейтингу.

Различные классы

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

  • 1xx – Информирующие о чем-либо.
  • 2xx – Сообщающие об успешном выполнении.
  • 3xx – Уведомляющие о перенаправлении.
  • 4xx – Сообщающие об ошибке клиента.

  • 5xx – Сообщающие об ошибке сервера.

Наиболее важные коды состояния HTTP для SEO

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

200: OK / Успешно

Вот как должно быть: клиент запрашивает у сервера контент и сервер отвечает сообщением 200. Это означает, что запрос прошел успешно – браузер получает содержимое, которое удовлетворяет потребностям клиента. И сервер, и клиент довольны. Пользователь счастлив. Все сообщения класса 2xx означают успешное выполнение какой-либо операции.

301: Перемещено навсегда

Заголовок HTTP 301 используется, когда запрашиваемый URL перемещен на новое место. Поскольку вы работаете с сайтом, с кодом придется сталкиваться часто – чтобы перенаправить старый URL на новый, вам обязательно нужно делать 301 редирект. Если вы этого не сделаете, пользователи, открывая старый URL, увидят страницу с кодом ошибки (404).

Подробнее о редиректе читайте в статье 10 популярных 301 редиректов в .htaccess

302: Найдено

Код состояния HTTP 302 означает, что целевой контент был найден, но находится в другом месте. Это довольно неоднозначный код состояния – он не говорит, временная это ситуация или нет. Используйте 302 редирект только в том случае, если хотите временно перенаправить URL на другой источник, и вы уверены в том, что будете использовать URL снова. Этим кодом вы сообщаете поисковым системам, что URL-адрес будет использоваться, а значит ссылочный вес не перенесется на новый URL. Поэтому не пользуйтесь 302 редиректом при перемещении домена или серьезных изменениях в структуре сайта.

307: Временное перенаправление

Код состояния 307 заменяет 302 в спецификации HTTP1.1 и может рассматриваться как единственный истинный редирект. Вы можете использовать 307 если вам нужно временно перенаправить URL на новый, оставив оригинальный метод запроса без изменений. 307 выглядит как 302, за исключением того, что он конкретно сообщает о временном характере нового местоположения. Запрос может меняться с течением времени, поэтому клиент должен продолжать использовать оригинальный URL при создании новых запросов.

403: Запрещено

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

404: Не найдено

Код заголовка HTTP 404 – один из наиболее важных. Когда сервер дает ответ в виде ошибки 404, вы получаете информацию о том, что содержимое не было найдено, и, вероятно, удалено. Старайтесь не раздражать посетителей сообщениями с этим кодом, исправляйте ошибки как можно скорее. Используйте редирект для перенаправления посетителей сайта со старого URL на новую статью или страницу, которая имеет связанный контент.

Мониторьте 404 сообщения в интерфейсе ошибок (Crawl errors) Google Search Console и пытайтесь свести их количество к минимуму. Большое количество ошибок этого типа может быть расценено Google как признак плохого обслуживания, а это повлияет на рейтинг сайта.

410: Удален

Результат кода 410 такой же, как 404 – содержимое не было обнаружено. Тем не менее, с 410 вы сообщаете поисковым системам об удалении запрошенного содержимого. Таким образом, этот код намного конкретнее 404. В некотором смысле вы отдаете команду поисковой машине удалить URL из индекса. Перед тем, как окончательно удалить что-то с сайта, подумайте, есть ли где-нибудь эквивалент страницы. Если да, сделайте редирект. Если нет, страницу нужно удалить или улучшить.

451: Информация недоступна по юридическим причинам

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

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

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

503: Сервис недоступен

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

Работа с кодами состояния HTTP

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

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

В заключение

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

Владелец сайта – современный Микеланджело. У него есть бесформенный материал, цель и, возможно, вкус и навыки, достаточные для воплощения проекта. Но у владельца сайта есть и то, чего не было у скульпторов – Google Search Console, которая позволяет вовремя найти ошибки и устранить их.

Как это сделать? Откройте Google Search Console. Перейдите во вкладку «Crawl» > «Crawl Errors». Там вы сможете посмотреть, что происходит с сайтом и уладить проблемы.

В первую очередь разберитесь с внешними ссылками, ведущими на страницу. Google, как правило, сортирует ошибки по важности. Ошибки с внешними ссылками относятся к приоритетным. Чтобы посмотреть, откуда идет ссылка, кликнете по URL-адресу 404 страницы. В открывшейся вкладке выберите «Linked From» и посмотрите URL-ссылки на страницу. Убедитесь, что все 404 страницы перенаправлены 301 редиректом на релевантный URL.

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

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

Она должна содержать:

  • Уведомление о том, что пользователь открыл страницу, которая не существует.
  • Окно поиска.
  • Простую навигацию, с помощью которой пользователь получит доступ к тому, что искал.
  • Ссылку на главную страницу.

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

Полное руководство по кодам статуса HTTP. Список кодов состояния HTTP

Оставьте комментарий 6,950

Когда браузер для доступа браузера на страницу просмотра веб отправляет запрос на сервер, где веб. Когда браузер получает и отображает первую страницу, сервер, на котором эта страница будет возвращать (заголовок сервера) в заголовок HTTP код состояния для ответа на запрос содержит браузер.

Коды состояния HTTP на английском языке для кода HTTP статуса.

Вот некоторые коды состояния общих HTTP:

  • 200— запрос был успешным
  • 301— ресурсы (веб-страниц и т.д.) постоянно переносится на другой URL
  • 404 — ресурсы (веб-страниц и т.д.) запросили, не существует
  • 500 — Внутренняя ошибка сервера

HTTP код классификации состояния

Код состояния HTTP состоит из трех десятичных цифр, первое десятичное число определяет тип кодов состояния, последние две цифры не классифицированы эффект. код состояния HTTP делится на пять типов:

HTTP Список кодов состояния:

Код Описание
HTTP Список кодов состояния

Код состояния Код состояния английское название китайский описание
100 продолжать Продолжить. Клиент должен продолжать свою просьбу
101 Переключение протоколов Переключение протоколов. Протокол коммутации сервера на основании запроса клиента. Может только переключиться на более продвинутый протокол, например, чтобы перейти на новую версию протокола HTTP
200 хорошо Запрос был успешным. В основном используется для GET и POST запросов
201 созданный Он был создан. Успешные запросы и создан новый ресурс
202 Принято Принято. Мы приняли эту просьбу, но не завершил процесс
203 Неавторитетная информация Неавторизованный доступ к информации. Запрос был успешным. Но не в оригинальной мета информации, возвращаемый сервером, но копия
204 Нет Содержание Пустой. Сервер успешно обработал, но не вернулся содержание. В отсутствие обновленных страниц, чтобы обеспечить браузер продолжает отображать текущий документ
205 Reset Content Сброс содержимого. Сервер обработки успешно, пользовательский терминал (например: браузер) должен вернуться к режиму просмотра документа. Этот код возврата может очистить поля формы вашего браузера
206 Частичное Содержание Часть. Сервер успешно обработал часть запроса GET
300 множественным выбором Разнообразие вариантов. Запрос ресурсов может включать в себя множество позиций, соответствующих возвращать список характеристик ресурсов и адреса для пользовательского терминала (например: браузер) Выберите
301 Переехал Постоянно Переехал Постоянно. Запрашиваемый ресурс был окончательно перемещен на новый URI, возвратит информацию, включая новый URI, браузер автоматически будет направлено на новый URI. Любой будущий новый запрос должен быть заменен на новый URI
302 найденный Временный ход. Подобно 301. Но ресурс временно перемещен. Клиент должен продолжать использовать оригинальный URI
303 См Другие Посмотреть другой адрес. Подобно 301. Используйте GET и POST запросы View
304 Not Modified Unmodified. Запрошенный ресурс неизмененной, сервер возвращает этот код статуса, он не возвращает каких-либо ресурсов. Клиент, как правило, кэширует ресурсы, посещаемые путем предоставления заголовка указывает на то, что клиент желание вернуться только после указанной даты модифицированного ресурса
305 Использовать прокси-сервер Используйте прокси-сервер. Запрошенный ресурс должен быть доступен через прокси-сервер
306 неиспользуемый Он был оставлен без присмотра HTTP код статуса
307 Временное перенаправление Временное перенаправление. Подобно 302. запрос использования GET перенаправляется
400 Bad Request Синтаксическая ошибка в запросах клиента, сервер не может понять,
401 неразрешенный Запрос требует аутентификации пользователя
402 Требуется оплата Зарезервировано для будущего использования
403 запрещенный Сервер понял запрос на запрос клиента, но отказался выполнять эту просьбу
404 Не найдено Сервер не может найти ресурсы (Web) по просьбе клиента. С помощью этого кода, разработчики сайта могут установить «ресурс, который вы запросили, не может быть найден» персональная страница
405 Method Not Allowed Заказчик поручает, запрещенные методы
406 Не Приемлемый Сервер не может выполнить запрос на основе характеристик контента, запрошенных клиентом
407 Требуется проверка подлинности прокси Запрос требует прокси-аутентификации, подобный 401, но отправитель должен использовать авторизацию прокси
408 Запрос Тайм-аут Сервер ожидает клиента, чтобы послать запрос слишком долго, тайм-аут
409 конфликт Столкновения сервера выполнить запрос PUT клиента может возвращать этот код, когда сервер обрабатывает запрос
410 прошло Ресурс по требованию клиента уже не существует. В отличие от 410 404, если ресурс теперь безвозвратно удалены, прежде чем вы можете использовать 410 код, веб-дизайнер может указать ресурсы с помощью нового кода местоположения 301
411 Длина Обязательный Сервер не смог обработать сообщение запроса, отправленного клиентом без Content-Length
412 Precondition Failed Предпосылки клиент запрашивает информацию ошибок
413 Слишком большой размер запроса Так как объект запроса слишком велик, сервер не может обработать, так что запрос будет отклонен. Для того, чтобы предотвратить непрерывную запрос клиента, сервер может закрыть соединение. Если сервер временно не может обрабатывать только, он будет содержать информацию о отклике Retry-After
414 Request-URI Too Large URI слишком длинный запрос (URI, как правило, URL-адрес), сервер не может обработать
415 Неподдерживаемый Тип носителя Сервер не смог обработать запрос, поставляемой вместе с медиа-форматов
416 Запрошенный диапазон не выполнима запрос клиента Диапазон недопустим
417 Expectation Ошибка Сервер не может удовлетворить запрос заголовок Expect
500 Внутренняя ошибка сервера Внутренняя ошибка сервера и не смог выполнить запрос
501 Не реализовано Сервер не поддерживает запрашиваемую функцию, не может выполнить запрос
502 Bad Gateway В качестве сервера шлюза или прокси-сервер, полученный от удаленного сервера на недопустимый запрос
503 Сервис недоступен Потому что он перегружен или обслуживания системы, сервер временно не может обработать запрос клиента. Длина задержки, она может быть включена в Retry-After информации заголовка сервера
504 Шлюз Тайм-аут Действуя в качестве шлюза или прокси-сервер, а не своевременный запрос на доступ с удаленного сервера
505 Версия HTTP не поддерживается Сервер не поддерживает запрошенный HTTP версия протокола не закончить обработку

Введение новых кодов должно производиться только после согласования с IETF . Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With . Так же упоминается пояснительная фраза «Reply With» в спецификации по WebDAV в Microsoft Developer Network , введённый Microsoft и 509 Bandwidth Limit Exceeded , введённый в cPanel . Компания Google предложила комитету IETF использовать HTTP-код 451 для уведомления о преднамеренном блокировании порталов .

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

Веб-сервер Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды, записывая их через точку после основного. При этом в ответах от сервера данный подкод не размещается — он нужен администратору сервера чтобы тот мог более точно определять источники проблем.

Обзорный список

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

  • (информационные):
  • (успешно):
  • (перенаправление):
  • (ошибка клиента):
  • (ошибка сервера):

Описание кодов

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

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

  • 100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
  • 101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update . Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
  • 102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV .

Успех

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

Перенаправление

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

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT) . Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302 . Изменять метод нужно только если сервер ответил 303 . В остальных случаях следующий запрос производить с исходным методом.

Поведение клиентов при различных перенаправлениях описано в таблице:

  • 300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME , по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
  • 301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
  • 302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location . Этот код может быть использован, например, при управляемом сервером согласовании содержимого . Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
  • 303 See Other — документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307 -ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET . Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST , включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303 , указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
  • 304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET , использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
  • 305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер , URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
  • 306 (зарезервировано) — использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
  • 307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

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

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

  • 400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
  • 401 Unauthorized — запрос требует идентификации пользователя. Сервер должен запросить имя и пароль у пользователя, а тот передаст их в заголовке WWW-Authenticate в следующем запросе. Если были указаны неверные данные, то сервер снова вернёт этот же статус. Появился в HTTP/1.0.
  • 402 Payment Required — предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

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

  • 403 Forbidden — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ или при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения . В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
  • 404 Not Found — самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код . Ответ 404 может использоваться вместо , если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
  • 405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow , разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код . Появился в HTTP/1.1.
  • 406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD , то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
  • 407 Proxy Authentication Required — ответ аналогичен коду за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
  • 408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT . В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потеря связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
  • 409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT .Появился в HTTP/1.1.
  • 410 Gone — такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код . Появился в HTTP/1.1.
  • 411 Length Required — для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT . Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
  • 412 Precondition Failed — возвращается, если ни одно из условных полей заголовка [неизвестный термин ] запроса не было выполнено. Появился в HTTP/1.1.
  • 413 Request Entity Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
  • 414 Request-URL Too Long — сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET , а не POST . Появился в HTTP/1.1.
  • 415 Unsupported Media Type — по каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
  • 416 Requested Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range . Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges . Введено в RFC 2616 (обновление HTTP/1.1).
  • 417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
  • 422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML -документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV .
  • 423 Locked — целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV .
  • 424 Failed Dependency — реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV .
  • 425 Unordered Collection — посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного [уточнить ] . Введено в черновике по WebDAV Advanced Collections Protocol .
  • 426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection . Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
  • 449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request . Введено корпорацией Microsoft для WebDAV . В настоящий момент как минимум используется программой Microsoft Money .
  • 456 Unrecoverable Error — возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV .

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

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

См. также

Примечания

Ссылки

Основные документы по протоколу HTTP (по убыванию даты публикации):

  • Hypertext Transfer Protocol (HTTP) Status Code Registry (англ.) . IANA (17 октября 2007). — реестр кодов состояния HTTP. Архивировано из первоисточника 17 февраля 2012. Проверено 30 июля 2009.
  • RFC 2616 Draft standard « » (англ.) (русск. ); IETF , июнь 1999; Fielding Roy (англ.) русск. (UC Irvine (англ.) русск. ), Gettys Jim (англ.) русск. (Compaq /W3C), Mogul J. (Compaq), Frystyk Henrik (англ.) русск. (MIT /W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C /MIT) — обновление протокола HTTP версии 1.1.
  • RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1 » (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1» ); IETF , январь 1997; Fielding Roy (англ.) русск. (UC Irvine (англ.) русск. ), Gettys Jim (англ.) русск. (DEC), Mogul J. (DEC), Frystyk Henrik (англ.) русск. (MIT /LCS), Berners-Lee Tim (MIT /LCS) — ранняя спецификация по HTTP версии 1.1.
  • RFC 1945 Informational «

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

HTTP коды 1хх – информационные коды. HTTP коды 2хх – успешные коды. HTTP код 3хх – коды перенаправления. HTTP код 4хх – коды ошибок клиента. HTTP код 5хх – коды ошибок сервера.

Если вы хотите узнать , обратитесь к .Код состояния – это элемент ответа , который представляет собой три цифры, первая цифра показывает к какому классу состояния относится тот или иной . В HTTP насчитывают всего пять классов кодов состояний : 1хх, 2хх, 3хх, 4хх, 5хх. HTTP коды состояний расширяемы, любой разработчик сервера может добавлять свои коды. Каждый код состояния очень тесно связан с : если метод – это элемент , то код состояния это сервера, который означает то, как сервер понял запрос.

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

Номер HTTP код состояния и его описание
1 HTTP коды состояний 1xx: Такой код состояния сервер высылает в том случае, когда запрос получен, но еще не обработан.
2 HTTP коды состояний 2 xx :
Сервер отправит вам такой код в том случае, когда он успешно принял и обработал клиента.
3 HTTP коды состояний 3 xx :
Если вы получили от сервера код состояния, начинающийся на тройку, то это означает, что нужны дополнительные действия, чтобы завершить процесс обработки HTTP запроса.
4 HTTP коды состояний 4 xx :

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

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

Коды состояния HTTP, такие как 404, 301 и , едва ли имеют значение для пользователей, но для оптимизаторов они невероятно важны. Мало того, что роботы поисковых систем (как Googlebot) используют их для определения здоровья сайта, коды состояния помогают узнать, что происходит между браузером и сервером. Некоторые из них указывает на ошибку, например, сигнализируют о том, что запрошенное содержимое не может быть найдено, в то время как другие просто выводят запрашиваемый материал. В этой статье мы пристальнее посмотрим на важнейшие коды HTTP заголовков и узнаем, что они означают для SEO.

Что такое коды состояния HTTP и почему вы их видите?

Код состояния HTTP – это сообщение, которое посылается сервером при отправке запроса с браузера, о том, может ли быть выполнен запрос или нет. Согласно официальной спецификации W3C, существуют десятки кодов состояния, со многими из которых вы вряд ли столкнетесь. А если столкнетесь, полный обзор возможных вариантов можно посмотреть на HTTPstatuses.com.

Чтобы понять эти коды, вам стоит знать, как браузер получает веб-страницу.

Добраться до веб-сайта пользователь может двумя способами – набрав URL сайта или введя запрос в строке поиска. После этого браузер посылает запрос на IP-адрес сайта, для получения соответствующей веб-страницы. Сервер отвечает браузеру, отправляя код состояния, встроенный в заголовок HTTP. Когда все нормально, код заголовка HTTP 200 отправляется обратно в браузер, вместе с запрошенным контентом.

Однако с запрашиваемым контентом или сервером что-то может быть не так. Например, не найдена страница (тогда возвращается код ошибки 404) или есть временная техническая проблема с сервером, в результате чего появляется код внутренней ошибки сервера 500. Эти коды статуса HTTP – важные инструменты для оценки состояния здоровья сайта и его сервера. Если сайт регулярно посылает неправильные коды заголовка HTTP в поисковую систему, его содержимое не индексируется, что, в свою очередь, вредит рейтингу.


Различные классы

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

  • 1xx – Информирующие о чем-либо.
  • 2xx – Сообщающие об успешном выполнении.
  • 3xx – Уведомляющие о перенаправлении.
  • 4xx – Сообщающие об ошибке клиента.
  • 5xx – Сообщающие об ошибке сервера.

Наиболее важные коды состояния HTTP для SEO

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

200: OK / Успешно

Вот как должно быть: клиент запрашивает у сервера контент и сервер отвечает сообщением 200. Это означает, что запрос прошел успешно – браузер получает содержимое, которое удовлетворяет потребностям клиента. И сервер, и клиент довольны. Пользователь счастлив. Все сообщения класса 2xx означают успешное выполнение какой-либо операции.

301: Перемещено навсегда

Заголовок HTTP 301 используется, когда запрашиваемый URL перемещен на новое место. Поскольку вы работаете с сайтом, с кодом придется сталкиваться часто – чтобы перенаправить старый URL на новый, вам обязательно нужно делать 301 редирект. Если вы этого не сделаете, пользователи, открывая старый URL, увидят страницу с кодом ошибки (404).

302: Найдено

Код состояния HTTP 302 означает, что целевой контент был найден, но находится в другом месте. Это довольно неоднозначный код состояния – он не говорит, временная это ситуация или нет. Используйте 302 редирект только в том случае, если хотите временно перенаправить URL на другой источник, и вы уверены в том, что будете использовать URL снова. Этим кодом вы сообщаете поисковым системам, что URL-адрес будет использоваться, а значит ссылочный вес не перенесется на новый URL. Поэтому не пользуйтесь 302 редиректом при перемещении домена или серьезных изменениях в структуре сайта.

307: Временное перенаправление

Код состояния 307 заменяет 302 в спецификации HTTP1.1 и может рассматриваться как единственный истинный редирект. Вы можете использовать 307 если вам нужно временно перенаправить URL на новый, оставив оригинальный метод запроса без изменений. 307 выглядит как 302, за исключением того, что он конкретно сообщает о временном характере нового местоположения. Запрос может меняться с течением времени, поэтому клиент должен продолжать использовать оригинальный URL при создании новых запросов.

403: Запрещено

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

404: Не найдено

Код заголовка HTTP 404 – один из наиболее важных. Когда сервер дает ответ в виде ошибки 404, вы получаете информацию о том, что содержимое не было найдено, и, вероятно, удалено. Старайтесь не раздражать посетителей сообщениями с этим кодом, исправляйте ошибки как можно скорее. Используйте редирект для перенаправления посетителей сайта со старого URL на новую статью или страницу, которая имеет связанный контент.

Мониторьте 404 сообщения в интерфейсе ошибок (Crawl errors) Google Search Console и пытайтесь свести их количество к минимуму. Большое количество ошибок этого типа может быть расценено Google как признак плохого обслуживания, а это повлияет на рейтинг сайта.

410: Удален

Результат кода 410 такой же, как 404 – содержимое не было обнаружено. Тем не менее, с 410 вы сообщаете поисковым системам об удалении запрошенного содержимого. Таким образом, этот код намного конкретнее 404. В некотором смысле вы отдаете команду поисковой машине удалить URL из индекса. Перед тем, как окончательно удалить что-то с сайта, подумайте, есть ли где-нибудь эквивалент страницы. Если да, сделайте редирект. Если нет, страницу нужно удалить или улучшить.

451: Информация недоступна по юридическим причинам

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

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

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

503: Сервис недоступен

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

Работа с кодами состояния HTTP

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

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

В заключение

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

Владелец сайта – современный Микеланджело. У него есть бесформенный материал, цель и, возможно, вкус и навыки, достаточные для воплощения проекта. Но у владельца сайта есть и то, чего не было у скульпторов – Google Search Console, которая позволяет вовремя найти ошибки и устранить их.

Как это сделать? Откройте Google Search Console. Перейдите во вкладку «Crawl» > «Crawl Errors» . Там вы сможете посмотреть, что происходит с сайтом и уладить проблемы.

В первую очередь разберитесь с внешними ссылками, ведущими на страницу. Google, как правило, сортирует ошибки по важности. Ошибки с внешними ссылками относятся к приоритетным. Чтобы посмотреть, откуда идет ссылка, кликнете по URL-адресу 404 страницы. В открывшейся вкладке выберите «Linked From» и посмотрите URL-ссылки на страницу. Убедитесь, что все 404 страницы перенаправлены 301 редиректом на релевантный URL.

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

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

Она должна содержать:

  • Уведомление о том, что пользователь открыл страницу, которая не существует.
  • Окно поиска.
  • Простую навигацию, с помощью которой пользователь получит доступ к тому, что искал.
  • Ссылку на главную страницу.

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

Невозможно без знания ответов сервера.

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

На сегодняшний день выделено 5 основных классов кода ответа:

1xx: Informational (рус. Информационный) — запрос правильно воспринят, но его обработка не завершена.

2xx: Success (рус. Успешно) — запрос правильно воспринят и успешно обработан.

3xx: Redirection (рус. Перенаправление) — коды переадресации на другие страницы.

4xx: Client Error (рус. Ошибка клиента) — ошибка со стороны клиента.

5xx: Server Error (рус. Ошибка сервера) — ошибка со стороны сервера.

А теперь давайте по отдельности разберем некоторые коды состояния IANA.

Ответ сервера 1XX

100 Continue Server Code

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

101 Switching Protocols

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

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

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

Ответ сервера 200 ОК

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

Ответ сервера 301

Также является одним из распространенных кодов ответа. Он сообщает, что запрашиваемая страница по данному адресу более не доступна, а затем происходит перенаправление на другой адрес. 301 редирект может применяться, например, при «переезде» сайта с протокола HTTP на HTTPS (обычно это реализуется через файл.htaccess, доступный на серверах Apache).

Ответ сервера 302

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

Ответ сервера 404

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

Фейковые страницы 404

Большинство вебмастеров не обращает на 404-тые страницы никакого внимания, однако, это может серьезно навредить ранжированию сайта. Парадокс, но страница с сообщением 404 File Not Found далеко не всегда отдает код 404. Такие страницы принято называть «Soft 404». Причины возникновения просты — по каким-то причинам страница отдает код, отличный от 404 и 410 — например, 200. Такое вполне возможно, если страница уже создана, но контента на ней пока нет.

Ответ сервера 500

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

500 Internal Server Error

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

Ответ сервера 502

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

Ответ сервера 550

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

На выходе будет представлена таблица.

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

ВАЖНО! Смешивание MX-записей недопустимо, т.е. в таблице на выдаче должны быть только те MX-записи, которые нужны именно для вашей почты . При необходимости нужно скорректировать записи, исправив ошибки и/или удалив лишнее.

Как получить коды ответа сервера (страницы) через Яндекс

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

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

Теперь переходим в сервис Яндекса (http://webmaster.yandex.ru/server-response.xml), с помощью которого можно посмотреть на сайт глазами робота и проверить скорость ответа сервера в Яндекс панели.

Просто вставляем url-адрес интересующей нас страницы в текстовое поле и нажимаем на кнопку «Проверить». В данном случае мы получили код 200 ОК, свидетельствующий о нормальной работе страницы.

Шаг 2. Проверяем ответ сервера на заведомо несуществующую страницу.

В том же сервисе вводим имя_домена/какая-то_крокозябра

В данном случае мы получили ответ 301 Moved Permanently. Это говорит о том, что адрес страницы указан неверно и происходит переадресация на правильный адрес.

Как еще узнать коды ответа сервера (сайта)?

В качестве альтернативы можно пробить код ответа с помощью сервиса http://mainspy.ru . Работает аналогично сервису Яндекса: вставляем интересующий URL и жмем «Проверить». Код ответа в данном случае находится в самой первой строке:

Bertal, в отличие от Mainspy, позволяет взглянуть на страницу не только глазами Яндекс-бота, но и глазами поисковых роботов Bing и Google, а в качестве бонуса — может эмулировать популярные браузеры. Для удобства взглянем на те же страницы глазами GoogleBot. В данном случае код ответа подсвечен зеленым.

Массовая проверка ответов сервера (сайта) онлайн

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


Dimax.biz — http://backlinks-checker.dimax.biz/tools/proverka_otveta_servera.php — это один из лучших чекеров. Единственный минус — в бесплатном режиме можно делать не более 2 запросов по 50 ссылок каждый. Для более «серьезных» объемов придется воспользоваться платным PRO-тарифом. На выходе мы получаем список, отсортированных по коду ответа. В данном случае в сортировке нет необходимости, т.к. в списке всего 2 адреса, и оба отдают код 200.

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

Как проверить скорость (время) ответа сервера сайта?

Сколько таких сервисов уже развелось — не пересчитать. Рассмотрим некоторые из них.

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

Which Loads Faster

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

Google PageSpeed Insights

Google PageSpeed Insights так же является одним из самых мощных инструментов для измерения скорости работы мобильной и десктопной версии. Оценка производится по 100-бальной шкале. 85 баллов и более — это хороший показатель. Плюс бонусом он выдает рекомендации по улучшению.

Долгий ответ сервера

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

Сложная логика предоставления данных

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

Сами запросы (либо сложные, либо неоптимизированные, либо и то и другое)

Запросы к большому количеству внешних ресурсов

Большое количество исполняемых файлов

Сам веб-сервер долго обрабатывает запрос.

Самые «больные» места производительности сервера:

Используемый веб-сервер (Apache, IIS).

Ряд веб-серверов даже при выдаче статических файлов могут создавать задержки, т.к. они на архитектурном уровне не предназначены для обработки большого количества запросов и из-за этого может быть сообщения что превышено время ожидания ответа от сервера. Поэтому для нормальной работы веб-сервера имеет смысл использовать nginx (причем в связке с Apache, php-fpm, а также остальными серверами приложений для обработки серверных вычислений).

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

Запросы к базе данных.

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

Сложная логика обработки данных.

Третий шаг — упрощение серверной логики. По сути, это просто устранение ненужных операций и профилирование времени выполнения серверных скриптов.

Обращение к сторонним сервисам.

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

Почему скорость ответа веб сервера влияет на продвижение.

Во-первых, потому что скорость загрузки является одним из факторов ранжирования (хоть и не решающим). Google открыто заявляет, что по скорости показа страниц ранжируется менее 1% сайтов. НО…

Во-вторых, если страница слишком долго грузится — пользователь ее просто закроет. Такое поведение пользователя принято называть «отказом». К слову, «отказы» оказывают прямое влияние на позиции в поисковой выдаче. Чем выше скорость загрузки — тем ниже процент отказов и, как следствие, тем выше позиции.

Превышено время ожидания ответа от сервера .

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

Основных же причин сбоя может несколько:

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

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

Что делать для решения?

Если сбой единичен — перезагружаем страницу с помощью комбинации Ctrl+F5. Возможно, потребуется перезагрузить страницу несколько раз. Если не помогло — проверяем подключение к интернету.

1. Некоторые сайты иногда «капризничают». Для динамического IP решение будет простым — перезагрузить роутер через отключение питания.

2. Медленное соединение иногда провоцирует ошибку ERR_CONNECTION_TIMED_OUT. Скорость работы интернета можно проверить через Яндекс-интернетометр . Если скорость слишком низкая — следует обратиться к интернет-провайдеру.

3. Необходимо проверить «Свойства сети» на наличие посторонних DNS-адресов. Если такие адреса имеются — удалить (предварительно на всякий случай переписав их куда-нибудь) и проверить систему на вирусы с помощью установленного на ПК антивирусного ПО — NOD32, Kaspersky, AdwCleaner, MalwareBytes, Dr.Web и т.д. Лучше всего для этих целей использовать Live-загрузчики.

4. Проверить настройки самого роутера. Наиболее часто сбивается параметр MTU. Универсальных рекомендаций по настройке роутера дать невозможно, т.к. это напрямую зависит и от модели роутера, и от интернет-провайдера. Обычно MTU имеет значения 1500, 1460, 1476.

Какое должно быть время ответа сервера?

И сразу же конкретные цифры:

Самая высокая конверсия у страниц, которые полностью загружаются за 1,8 и 2,7 секунды для десктопной и мобильной версий соответственно

Самый низкий показатель отказов у страниц, которые полностью загружаются за 1 и 0.7 секунды для десктопной и мобильной версий соответственно

Данные цифры позаимствованы из исследования Akamai Technologies.

Итак, Вы проверили сайт на скорость загрузки. Но как реагировать на результаты?

Список кодов состояния HTTP — List of HTTP status codes

Это список Hypertext Transfer Protocol (HTTP) кодов состояния ответа. Коды статуса выдаются сервером в ответ на запрос клиента к серверу. Она включает в себя коды от IETF Запроса на комментарии (РЛК), другие спецификации, а также некоторые дополнительные коды , используемые в некоторых общих применениях протокол передачи гипертекста (HTTP). Первая цифра кода состояния определяет один из пяти стандартных классов ответов. Фразы сообщений являются типичными, но может быть предоставлена любой человек-считываемой альтернатива. Если не указано иное, код состояния является частью HTTP / 1.1 стандарта ( RFC 7231 ).

Internet Assigned Numbers Authority (IANA) поддерживает официальный реестр кодов состояния HTTP.

Microsoft Internet Information Services (IIS) иногда использует дополнительные десятичные суб-коды для получения более конкретной информации, однако эти суб-коды появляются только в полезной нагрузке отклика и в документации, но не в месте фактического кода состояния HTTP.

Все коды состояния ответа HTTP разделены на пять классов (или категории). Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют никакой роли класса или категоризации. Есть пять значений для первой цифры:

  • 1xx (информационный): Запрос был получен, непрерывный процесс
  • 2xx (успешный): запрос был успешно получен, понят и принят
  • 3xx (Перенаправление): Дальнейшие действия необходимо предпринять для того, чтобы завершить запрос
  • 4xx (Client Error): запрос имеет плохой синтаксис или не может быть выполнен
  • 5xx (ошибка сервера): Сервер не смог выполнить допустимый запрос

содержание

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

Информационный ответ указывает , что запрос был получен и поняты. Он выдается на временной основе , а обработка запроса продолжается. Он предупреждает клиента ждать окончательного ответа. Сообщение состоит только из строки состояния и необязательных полей заголовка, и завершается пустой строкой. Как стандарт HTTP / 1.0 не определял никаких 1xx кодов состояния, серверы не должны посылать 1xx ответы / совместимый клиент HTTP 1.0 , за исключением экспериментальных условий.

100 Продолжить Сервер получил заголовки запроса и клиент должен перейти к отправить тело запроса (в случае запроса , для которого тело должно быть отправлено, например, в POST запрос). Посылка большого тела запроса к серверу после того, как запрос был отклонен несоответствующих заголовков будет неэффективным. Чтобы сервер проверки заголовков запроса, клиент должен отправить в Expect: 100-continue качестве заголовка в его первоначальном запросе и получить 100 Continue код состояния в ответ перед отправкой тела. Если клиент получает код ошибки , такие как 403 (Forbidden) или 405 (Method Not Allowed) , то он не должен отправить тело запроса. Ответ 417 Expectation Failed указывает на то, что запрос должен быть повторен без Expect заголовка , поскольку это указывает на то, что сервер не поддерживает ожидания (это имеет место, например, HTTP / 1.0 серверов). 101 Switching Protocols Запрашивающая попросил сервер переключить протоколы, и сервер согласился сделать это. 102 Обработка ( WebDAV ; RFC 2518 ) Запрос WebDAV может содержать много вложенных запросов, связанных с операциями с файлами, которые требуют много времени для завершения запроса. Этот код указывает на то, что сервер получил и обрабатывает запрос, но никакого ответа не существует. Это предотвращает клиента от тайм-аута, и предполагая, что запрос был потерян. 103 Ранние подсказки (RFC 8297) Используется для возврата некоторых заголовков ответа перед окончательным сообщением HTTP.

2xx Успех

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

200 OK Стандартный ответ для успешных запросов HTTP. Фактический ответ будет зависеть от используемого метода запроса. В запросе GET, ответ будет содержать объект, соответствующий запрошенному ресурсу. В запросе POST, ответ будет содержать объект, описывающий или, содержащий результат действия. 201 Создано Требование было выполнено, в результате создания нового ресурса. 202 Принято Запрос был принят для обработки, но обработка не была завершена. Запрос может или не может быть в конечном счете действовал на, и может быть отменен, когда происходит обработка. 203 Неавторитетных данных (с HTTP / 1.1) Сервер является трансформирующий прокси (например, веб — ускоритель ) , который получил 200 OK от его происхождения, но возвращает модифицированную версию ответа происхождения в. 204 No Content Сервер успешно обработал запрос и не возвращает содержания. 205 Сброс содержимого Сервер успешно обработал запрос, но не возвращает содержания. В отличии от 204 ответа, этот ответ требует, чтобы запрашивающие изменений вида документа. 206 Partial Content ( RFC 7233 ) Сервер доставка только часть ресурса ( байты порция ) из — за заголовок диапазона , отправленный клиентом. Заголовок диапазона используется HTTP клиентами , чтобы позволить возобновления прерванной загрузки или разбить закачку на несколько одновременных потоков. 207 Multi-статуса (WebDAV; RFC 4918 ) Тело сообщения , которое следует по умолчанию XML сообщение и может содержать ряд отдельных кодов ответа, в зависимости от того, как были сделаны много подзапросов. 208 Уже сообщалось (WebDAV, RFC 5842 ) Члены в DAV связывание уже перечислены в предыдущей части (multistatus) ответ, и не включаются снова. 226 IM Used ( RFC 3229 ) Сервер выполнил запрос ресурса, и реакция является представление результата одного или нескольких экземпляров-манипуляций, применяемых к текущему экземпляру.

3xx Перенаправление

Этот класс кода статуса указывает , что клиент должен принять дополнительные меры для выполнения запроса. Многие из этих кодов состояния используются в URL перенаправления .

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

300 Multiple Choices Указывает несколько вариантов ресурса , с которого клиент может выбрать ( с помощью агента для работы с содержанием переговоров ). Например, этот код может быть использован для представления нескольких вариантов формата видео, чтобы просмотреть список файлов с различными расширениями , или предложить разрешение лексической многозначности . 301 перемещена Постоянно Это и все последующие запросы должны быть направлены к данному URI . 302 Найдено (Ранее «временно перемещено») Сообщает клиенту, чтобы посмотреть на (перейдите) другой URL. 302 был заменен 303 и 307. Это является примером отраслевой практики, противоречащей стандарт. HTTP / 1.0 спецификация (RFC 1945) требуется клиенту выполнить временный редирект (оригинал описания фраза «Временно перемещено»), но популярные браузеры реализованы 302 с функциональностью 303 See Other. Поэтому HTTP / 1.1 добавлен коды статуса 303 и 307, чтобы различать эти два поведения. Тем не менее, некоторые веб-приложения и среды используют код 302 состояния, как если бы это было 303. 303 См Другое (так как HTTP / 1.1) Ответ на запрос может быть найден под другим URI с помощью метода GET. При получении в ответ на POST (или PUT / DELETE), клиент должен предположить , что сервер получил данные и должны выдавать новый запрос GET к данному URI. 304 Not Modified ( RFC 7232 ) Указывает , что ресурс не был изменен , так как версия указано в заголовках запросов If-Modified-Since или If-None-Match. В таком случае нет необходимости повторно ресурса , так как клиент все еще имеет ранее загруженную копию. 305 Использовать прокси (с HTTP / 1.1) Запрашиваемый ресурс доступен только через прокси — сервер, адрес , для которого предусмотрен в ответ. Многие клиенты HTTP (такие как Mozilla Firefox и Internet Explorer ) не правильно обрабатывать ответы этого кода состояния, в первую очередь по соображениям безопасности. 306 Переключатель прокси больше не используется. Первоначально означал «Последующие запросы должны использовать указанный прокси-сервер.» 307 Временное перенаправление (с HTTP / 1.1) В этом случае запрос должен быть повторен с другими URI; Однако будущие запросы должны по-прежнему использовать оригинальный URI. В отличие от того, как 302 был исторически реализован, метод запроса не может быть изменена, если переоформление первоначальный запрос. Например, запрос POST должен быть повторен с использованием другого запроса POST. 308 Постоянная Перенаправление ( RFC 7538 ) Запрос и все последующие запросы должны быть повторены с использованием другого URI. 307 и 308 параллельно с поведением 302 и 301, но не позволяют метод HTTP изменить . Так, например, подав форму постоянно перенаправлены ресурс может продолжаться гладко.

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

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

ошибка 400, неверный запрос Сервер не может или не будет обрабатывать запрос из-за явную ошибку клиента (например, неверный формат синтаксис запроса, размер слишком большим, некорректное кадрирование сообщения запроса или обманчивой маршрутизацию запроса). 401 Несанкционированное ( RFC 7235 ) Подобно 403 Forbidden , но специально для использования , когда требуется проверка подлинности и не удалось или до сих пор не предусмотрено. Ответ должен включать поле заголовка WWW-Authenticate , содержащее вызов , применимое к запрошенному ресурсу. См обычной проверки подлинности доступа и аутентификация доступа Digest . 401 семантический означает «неаутентифицированный» , то есть пользователь не имеет необходимые полномочия. Примечание: Некоторые сайты неправильно выдавать HTTP 401 , когда IP — адрес запрещен с веб — сайта (обычно домена сайта) , и что конкретный адрес отказано разрешение на доступ к веб — сайт. Обязательный 402 Оплата Зарезервировано для будущего использования. Первоначально предполагалось , что этот код может быть использован как часть той или иной форме цифровой наличности или микроплатежей схемы, как это было предложено, например , с помощью GNU талера, но это еще не произошло, и этот код обычно не используется. Google Developers API использует этот статус , если конкретный разработчик превысил дневной лимит на запросы. Sipgate использует этот код , если учетная запись не имеет достаточных средств , чтобы начать вызов. Shopify использует этот код , когда в магазине не выплатили свои взносы и временно отключена. 403 Forbidden Запрос был действителен, но сервер отказывается действовать. Пользователь не может иметь необходимые права доступа к ресурсу, или может потребоваться счет какого-то. 404 Не Найдено Запрашиваемый ресурс не может быть найден, но могут быть доступны в будущем. Последующие запросы от клиента допустимы. 405 Method Not Allowed Способ запроса не поддерживается для запрошенного ресурса; например, запрос GET по форме , которая требует данных , которые будут представлены с помощью POST , или запрос PUT на ресурс только для чтения. 406 Не Приемлемый Запрошенный ресурс способен генерировать только содержание не допустимо в соответствии с Accept заголовками , отправленных в запросе. См согласование содержания . 407 Требуется проверка подлинности прокси ( RFC 7235 ) Клиент должен сначала идентифицировать себя с прокси . 408 Запрос тайм-аута Сервер истекло время ожидания запроса. Согласно спецификации HTTP: «Клиент не произвел запрос в течение времени, что сервер был подготовлен ждать Клиент может повторить запрос без модификаций позднее в любое время.» 409 конфликтов Указывает , что запрос не может быть обработан из — за конфликта в текущем состоянии ресурса, такого как редактировать конфликт между несколькими одновременными обновлениями. 410 Исчезли Указывает, что ресурс просил больше не доступны и не будут доступны снова. Это должно использоваться, когда ресурс был намеренно удалены и ресурс должен быть очищен. После получения кода на 410 статусов, клиент не должен запросить ресурс в будущем. Клиенты, такие как поисковые системы должны удалить ресурс из их индексов. В большинстве случаев использование не требует от своих клиентов и поисковых систем, чтобы очистить ресурс, и «404 Not Found» может быть использован вместо. 411 Длина Требуемое Просьба не указывать длину его содержания, которое требуется запрашиваемый ресурс. 412 Precondition Failed ( RFC 7232 ) Сервер не отвечает одна из предпосылок, что запрашивающая ставят на запрос. 413 Полезная нагрузка слишком велико ( RFC 7231 ) Запрос больше, чем сервер желает или способен обработать. Ранее называлась «Request Entity Too Large». 414 URI слишком долго ( RFC 7231 ) URI при условии , был слишком длинным для обработки сервера. Часто результат слишком большое количество данных кодируются как строки запроса запроса GET, в этом случае он должен быть преобразован в запрос POST. Названный «Request-URI Too Long» ранее. 415 неподдерживаемый Тип носителя Объект запроса имеет тип носителя , который сервер или ресурс не поддерживает. Например, клиент будет загружать изображение в качестве изображения / SVG + XML , но сервер требует , чтобы изображения использовать другой формат. 416 Диапазон не выполнима ( RFC 7233 ) Клиент попросил часть файла ( байт сервировки ), но сервер не может предоставить эту часть. Например, если клиент попросил часть файла , который лежит за пределами конца файла. Названный «Запрошенный диапазон не выполнима» ранее. 417 Ожидание Ошибка Сервер не может отвечать требованиям поля заголовка запроса Expect. 418 Я чайник ( RFC 2324 , RFC 7168 ) Этот код был определен в 1998 году в качестве одного из традиционных IETF шуток первоапрельских , в RFC 2324 , Hyper Text Кофейный Control Protocol Горшок , и не ожидается, будет реализована реальными серверами HTTP. RFC определяет этот код должен быть возвращен чайники запрашиваемых варить кофе. Этот статус HTTP используется в качестве пасхального яйца в некоторых веб — сайтах, в том числе Google.com . 421 Запрос Неправильно ( RFC 7540 ) Запрос был направлен на сервере, который не в состоянии произвести реакцию (например, из-за повторное соединение). 422 Unprocessable сущностей (WebDAV; RFC 4918 ) Запрос был хорошо образован, но не смог следовать за счет семантических ошибок. 423 Locked (WebDAV; RFC 4918 ) Ресурс, который осуществляется доступ заблокирован. 424 Не удалось зависимостей (WebDAV; RFC 4918 ) Сбой запроса, потому что это зависит от другого запроса, и что запрос не удалось (например, PROPPATCH). 426 Требуется обновление Клиент должен переключиться на другой протокол , такие как TLS / 1.0 , приведенном в Upgrade заголовок поля. 428 Предпосылкой Обязательный ( RFC 6585 ) Сервер происхождения требует запроса быть условными. Предназначен для предотвращения «потерял обновление» проблему, когда клиент получает состояние ресурса, в модифицирует его, и возвращает его обратно на сервер, когда в то время третья сторона изменила положение на сервере, что приводит к конфликту. 429 Слишком много запросов ( RFC 6585 ) Пользователь отправил слишком много запросов в заданный промежуток времени. Предназначено для использования с лимитирующими схемами. 431 заголовка запроса Поля слишком большой ( RFC 6585 ) Сервер не обрабатывает запрос, так как физическое поле заголовка, или все поля заголовка в совокупности, являются слишком большими. 451 Недоступен по юридическим причинам ( RFC 7725 ) Оператор сервер получил юридическое требование запретить доступ к ресурсу или к набору ресурсов , который включает в себя запрошенный ресурс. Код 451 был выбран в качестве ссылки на повесть 451 градуса по Фаренгейту (см подтверждений в RFC).

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

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

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

500 — внутренняя ошибка сервера Сообщение общей ошибки, учитывая, когда неожиданная ситуацию и не более конкретное сообщение является подходящим. 501 Не реализовано Сервер либо не распознает метод запроса, или он не имеет возможности выполнить запрос. Обычно это подразумевает наличие в будущем (например, новая функция веб-сервис API). 502 Неверный шлюз Сервер, действуя в качестве шлюза или прокси — сервера, получил недопустимый ответ от вышестоящего сервера. сервис 503 недоступен Сервер временно недоступен (так как он перегружен или вниз для технического обслуживания). Как правило, это временное состояние. Ошибка 504 Время ответа сервера истекло Сервер, действуя в качестве шлюза или прокси-сервера и не получил своевременный ответ от вышестоящего сервера. 505 HTTP Version Not Supported Сервер не поддерживает версию протокола HTTP, использованную в запросе. 506 Вариант также ведет переговоры ( RFC 2295 ) Прозрачное содержание переговоры по результатам запроса в циклической ссылке . 507 Недостаточно хранения (WebDAV; RFC 4918 ) Сервер не может сохранить представление, необходимое для выполнения запроса. 508 Петля Обнаружен (WebDAV; RFC 5842 ) Сервер обнаружил бесконечный цикл при обработке запроса (посланный вместо 208 уже сообщалось ). 510 Не Extended ( RFC 2774 ) Дополнительные расширения для запроса требуется для сервера, чтобы выполнить его. 511 Network Authentication Required ( RFC 6585 ) Клиент должен проверить подлинность , чтобы получить доступ к сети. Предназначено для использования перехватывающей прокси , используемой для управления доступом к сети (например, « Пленные порталы » , используемых требовать согласий на Условие предоставления услуг перед предоставлением полного доступа к Интернету через точку доступа Wi-Fi ).

Неофициальные коды

Следующие коды не указаны по любому стандарту.

103 Контрольно-пропускной пункт Используется в предложении возобновляемых запросов возобновить прервынный PUT или POST-запросы. 218 Это нормально ( Apache Web Server ) Используются в качестве догоняющих всех условий ошибки для позволяя органов реагирования течь через Apache, когда ProxyErrorOverride включена. Когда ProxyErrorOverride включена в Apache, Ответные органы, которые содержат код состояния 4xx или 5xx автоматически отбрасываются Apache в пользу общего ответа или пользовательского ответа, указанного в директиве ErrorDocument. 419 Page Expired ( Laravel Framework ) Используется Laravel Framework, когда CSRF маркер отсутствует или истек. 420 Метод Неудача ( Spring Framework ) Устаревший ответ, используемый Spring Framework, когда метод не удалось. 420 Повысьте Calm ( Twitter ) Возвращается версии 1 API Twitter Поиск и тенденции , когда клиент является скорость ограничена; версии 1.1 и позже использовать в 429 Слишком много запросов код ответа вместо. 450 Заблокировано Родительский контроль Windows (Microsoft) Код расширения Microsoft указывается, когда Windows, Родительский контроль включается и блокирует доступ к запрашиваемой странице. 498 Недопустимый маркер (Esri) Возвращается ArcGIS для сервера . Код 498 указывает на просроченный или иначе неверный маркер. 499 Знак Обязательный (Esri) Возвращается ArcGIS для сервера . Код 499 указывает на то, что маркер не требуется , но не был представлен. 509 Полоса пропускания Превышен предел ( веб — сервер Apache / Cpanel ) Сервер превысил пропускную способность, заданный администратором сервера; это часто используется совместно хостинг-провайдеров, чтобы ограничить пропускную способность клиентов. 526 Недопустимый сертификат SSL Используется Cloudflare и Cloud Foundry gorouter «s , чтобы указать отказ проверять достоверность SSL / TLS сертификат, представленный сервер происхождения. 530 Сайт заморожен Используется Pantheon веб — платформы , чтобы указать сайт , который был заморожен из — за неактивности. 598 (Неформальная конвенция) Сеть чтения тайм-аут ошибки Используются некоторой HTTP прокси для сигнала сети таймаута за прокси для клиента перед прокси.

Информационные услуги Интернет

От Microsoft Internet Information Services веб — сервер расширяет пространство 4xx ошибок для сигнала ошибки с запросом клиента.

440 Войти Тайм-аут Сессия клиента истек, и необходимо снова войти в систему. 449 Retry С Сервер не может удовлетворить запрос, поскольку пользователь не предоставил необходимую информацию. 451 Redirect Используется в Exchange ActiveSync , когда либо более эффективный сервер доступен или сервер не может получить доступ к почтовым ящикам пользователей. Клиент , как ожидается , повторно запустить операцию HTTP AutoDiscover найти более подходящий сервер.

Nginx

Nginx программное обеспечение веб — сервер расширяет пространство 4xx ошибки сигнализировать проблемы с запросом клиента.

444 Нет ответа Используется внутри проинструктировать сервер не возвращать никакой информации клиента и сразу же закрыть соединение. 494 заголовка запроса слишком большой Клиент послал слишком большой запрос или слишком длинную строку заголовка. Ошибка 495 сертификата SSL Расширение 400 Bad Request кодом_ответа, используется , когда клиент предоставил неверный сертификат клиента . 496 SSL Обязательный сертификат Расширение 400 Bad Request кодом_ответа, используется , когда требуется сертификат клиента , но не предусмотрено. 497 HTTP запроса, отправленного на порт HTTPS Расширение 400 Bad Request кодом_ответа, используется , когда клиент сделал запрос HTTP к порту прослушивает запросы HTTPS. 499 Client Закрытый запрос Используется, когда клиент закрыл запрос до сервера может отправить ответ.

Cloudflare

Cloudflare обратного прокси сервис «ы расширяет серию 5xx ошибок пространства для сигнализации проблемы с сервером происхождения.

520 Неизвестная ошибка Ошибка 520 используется в качестве «всеобъемлющего ответа на когда исходный сервер возвращает что-то неожиданное», перечисляя сброс соединения, большие заголовки и пустые или недействительные ответы как общие триггеры. 521 Веб-сервер выключен Сервер происхождения отказал в соединении с Cloudflare. 522 Время ожидания подключения истекло Cloudflare не может вести переговоры TCP рукопожатия с сервером происхождения. 523 Происхождение недостижим Cloudflare не может получить доступ к серверу происхождения; например, если DNS — записи для сервера происхождения являются неправильными. 524 Тайм-аут Cloudflare смог завершить соединение TCP с сервером происхождения, но не получил своевременный ответ HTTP. 525 SSL рукопожатия Ошибка Cloudflare не может вести переговоры по протоколу SSL / TLS квитирование с сервером происхождения. 526 Недопустимый сертификат SSL Cloudflare не может проверить сертификат SSL на веб-сервере происхождения. 527 Железнодорожной Ошибка Ошибка 527 указывает на то, что запрос истекло или не после того, как подключение к глобальной сети была создана. Ошибка 530 Происхождение DNS Ошибка 530 указывает на то, что запрашиваемое имя хоста не может быть решена в сети Cloudflare на сервер происхождения.

Полный список кодов ответов HTTP, классы и описание

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

Классы кодов ответа HTTP

Всего есть 5 классов

В ТЕМУСТАТЬИ

Диагностика и технический анализ сайта на WordPress: главное что надо сделать и знать

Как оптимизировать ваш сайт WordPress для конверсий в целевые действия и улучшить связь с клиентом

Класс 1хх – информационные коды ответа HTTP.

100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

Класс 2xx коды HTTP – успешно

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

200 OK — успешный запрос.
202 Accepted — запрос был принят на обработку, но она не завершена.
203 Non-Authoritative Information — аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)
207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

Класс 3хх коды HTTP – перенаправление

Ответы HTTP начинающиеся на 3хх говорят о перенаправлении.

300 Multiple Choices («множество выборов»)
301 Moved Permanently («перемещено навсегда»)
302 Moved Temporarily («перемещено временно»)
302 Found («найдено»)
303 See Other (смотреть другое)
304 Not Modified (не изменялось)
305 Use Proxy («использовать прокси»)
306 — зарезервировано (код использовался только в ранних спецификациях)
307 Temporary Redirect («временное перенаправление»)

Класс 4хх ответы HTTP – ошибки клиента

4xx: Client Error (ошибка клиента)
400 Bad Request («плохой, неверный запрос»)
401 Unauthorized («не авторизован»)
402 Payment Required («необходима оплата»)
403 Forbidden («запрещено»)
404 Not Found («не найдено»)
405 Method Not Allowed («метод не поддерживается»)
406 Not Acceptable («неприемлемо»)
407 Proxy Authentication Required («необходима аутентификация прокси»)
408 Request Timeout («истекло время ожидания»)
409 Conflict («конфликт»)
410 Gone («удалён»)
411 Length Required («необходима длина»)
412 Precondition Failed («условие ложно»)
413 Request Entity Too Large («размер запроса слишком велик»)
414 Request-URI Too Large («запрашиваемый URI слишком длинный»)
415 Unsupported Media Type («неподдерживаемый тип данных»)
416 Requested Range Not Satisfiable («запрашиваемый диапазон не достижим»)
417 Expectation Failed («ожидаемое неприемлемо»)
422 Unprocessable Entity («необрабатываемый экземпляр»)
423 Locked («заблокировано»)
424 Failed Dependency («невыполненная зависимость»)
425 Unordered Collection («неупорядоченный набор»)
426 Upgrade Required («необходимо обновление»)
428 Precondition Required («необходимо предусловие»)
429 Too Many Requests («слишком много запросов»)
431 Request Header Fields Too Large («поля заголовка запроса слишком большие»)
434 Requested host unavailable. («Запрашиваемый адрес недоступен»)
444 Закрывает соединение без передачи заголовка ответа. Нестандартный код
449 Retry With («повторить с»)
451 Unavailable For Legal Reasons («недоступно по юридическим причинам»)

Класс 5хх ответы HTTP – внутренние ошибки сервера

500 Internal Server Error («внутренняя ошибка сервера»)
501 Not Implemented («не реализовано»)
502 Bad Gateway («плохой, ошибочный шлюз»)
503 Service Unavailable («сервис недоступен»)
504 Gateway Timeout («шлюз не отвечает»)
505 HTTP Version Not Supported («версия HTTP не поддерживается»)
506 Variant Also Negotiates («вариант тоже проводит согласование»)
507 Insufficient Storage («переполнение хранилища»)
508 Loop Detected («обнаружено бесконечное перенаправление»)
509 Bandwidth Limit Exceeded («исчерпана пропускная ширина канала»).
510 Not Extended («не расширено»).
511 Network Authentication Required «требуется сетевая аутентификация»

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

Данная страница основана на информации о кодах состяний HTTP. Оригинальными источниками являются ietf.org и Wikipedia. Кликните по заголовку категории или коду состояния для получения подробной информации.

1xx: Information


В этот класс выделены коды, информирующие о процессе передачи. Это обычно предварительный ответ, состоящий только из Status-Line и опциональных заголовков, и завершается пустой строкой. Нет обязательных заголовков для этого класса кодов состояния. Из-за того, что стандарт протокола HTTP/1.0 не определял никаких 1xx кодов состояния, серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам, за исключением экспериментальных условий.

Клиент должен быть готов принять один или несколько 1xx ответов статуса до завершения передачи, даже если клиент не ожидает статуса 100 (Продолжить). Неожиданные 1xx ответы могут быть проигнорированы агентом пользователя.

Прокси должен направить 1xx ответы, если соединение между прокси сервером и клиентом было закрыто, или если прокси сам просил 1xx ответ. (Например, если прокси добавляет «Expect: 100-continue» поле, когда он перенаправляет запрос, то нужно отправить соответствующий 100 (Continue) код ответа).

Wikipedia

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

Клиент должен продолжать свой Запрос. Этот промежуточный ответ используется для сообщения клиенту о том, что начальная часть запроса была получена и еще не был отвергнут сервером. Клиенту СЛЕДУЕТ продолжить посылку оставшихся данных запроса или, если запрос уже был выполнен, игнорировать этот ответ. Сервер ДОЛЖЕН послать заключительный ответ после того, как запрос был завершен. См. раздел 8.2.3 для детального обсуждения использования и обработки этого кода состояния.

Wikipedia

Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

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

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

Wikipedia

Сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.

Этот промежуточный ответ используется для информирования клиента о том, что сервер принял на себя полную запрос, но еще не завершил ее. Этот статус код должен быть посланы только когда сервер имеет разумные основания ожидать, что запрос займет значительное время. В качестве ориентира, если метод занимает больше времени, чем на 20 секунд (разумно, но произвольное значение) для обработки сервер должен вернуть 102 (Processing) ответ. Сервер ДОЛЖЕН послать заключительный ответ после того, как запрос был завершен.

Методы потенциально могут занять длительный период времени для процесса, особенно если они поддерживают заголовок Depth. В таких случаях клиент может прервать соединение по тайм-ауту во время ожидания ответа. Чтобы предотвратить это, сервер может вернуть 102 (Processing) код состояния, указывая клиенту, что сервер все еще обрабатывается методом.

Wikipedia

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

2xx: Success

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

Wikipedia

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

Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например:

  • GET Получить объект, соответствующий запрошенному ресурсу в ответ;
  • HEAD Поля заголовков, соответствующиe запрошенному ресурсу отправляются в ответ без какого-либо тела сообщения;
  • POST Созданный объект или иной результат действия;
  • TRACE Объект, содержащий сообщение запроса, полученное сервером.

Wikipedia

Стандартный ответ для запросов по HTTP.

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

Запрос был выполнен, и, в результате, создан новый ресурс. Вновь созданный ресурс может быть, на который ссылается URI (ы) возвращается в объекте ответа, с самым конкретным URI для ресурса отдается в поле заголовка Location. Ответ СЛЕДУЕТ включить объект, содержащий список характеристик и местоположения (ы), из которых пользователь или агент пользователя может выбрать наиболее подходящий. Формат объекта определяется тип носителя приведены в Content-Type заголовка поля. Первоначальный сервер ДОЛЖЕН создать ресурс перед возвратом кода состояния 201. Если действие не может быть выполнено немедленно, сервер должен ответить 202 (Принято) вместо ответа.

A 201 ответа может содержать поля заголовка ETag ответ с указанием текущего значения метки объекта на указанный вариант только что создали, см. раздел 14.19.

Wikipedia

Запрос был выполнен и в результате был создан новый ресурс.

Подтверждение успешного создания (например посредством POST или PUT запроса). Заголовок Location содержит ссылку на только что созданный ресурс (при POST запросе). Тело ответа может быть пустым. Обычно так и бывает.

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

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

Wikipedia

Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

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

Wikipedia

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

Появился в HTTP/1.1.

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

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

204 — должен не содержать тела ответа. Если таковая имеется — она обчно игнорируется и считается что после заголовков присутствет одна пустая линия.

Wikipedia

Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

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

Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяетс для возврата в начальное состояние формы ввода данных на клиенте.

Wikipedia

Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

Сервер выполнил часть GET запроса ресурса. Запрос ДОЛЖЕН был содержать поле заголовка Range (секция 14.35), которая указывает на желаемый диапазон и МОГ содержать поле заголовка If-Range (секция 14.27), который делает запрос условным.

Запрос ДОЛЖЕН содержать следующие поля заголовка:

  • Либо поле Content-Range (секция 14.16), который показывает диапазон, который включен в этот запрос, либо Content-Type со значением multipart/byteranges, включающими в себя поля Content-Range для каждой части. Если в заголовке запроса есть поле Content-Length, его значение ДОЛЖНО совпадать с фактическим количеством октетов, переданных в теле сообщения.
  • Date
  • ETag и/или Content-Location, если ранее был получен ответ 200 на такой же запрос.
  • Expires, Cache-Control, и/или Vary, если значение поля изменилось с момента отправения последнего такого же запроса

Если ответ 206 — это результат выполнения условного зарпоса, который использовал строгий кэш-валидатор (подробнее в секции 13.3.3), в ответ НЕ СЛЕДУЕТ включать какие-либо другие заголовки сущности. Если такой ответ — результат выполнения запроса If-Range, который использовал «слабый» валидатор, то ответ НЕ ДОЛЖЕН содержать другие заголовки сущности; это предотвращает несоответствие между закэшированными телами сущносей и обновленными заголовками. В противном случае, ответ ДОЛЖЕН содержать все заголовки сущностей, который вернули статус 200 (OK) на тот же запрос.

Кэш НЕ ДОЛЖЕН объединять ответ 206 с другими ранее закэшированными данными, если поле ETag или Last-Modified в точности не совпадают (подробнее в секции 16.5.4)

Кэш, который не поддерживает заголовки Range и Content-Range НЕ ДОЛЖЕН кэшировать ответы 206 (Partial).

Wikipedia

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

Код 207 (Multi-Status) позволяет передавать статусы для нескольких независимых операций (за подробностями в секцию 11).

Wikipedia

Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

Относится к DAV и был ранее включен в 207 ответ. Там поныне и остается.

Wikipedia

На сайте отписание отсуствует

Сервер успешно принял запрос для ресурса и ответ является представлением результата применения одной или нескольких манипуляций с инстансом ресурса. На самом деле актуальне представление ресурса может быть в текущий момент не доступно ввиду того, что действие может быть глобальное и затрагивать несколько инстансов ресурса, а соответственно может комбинироваться с предудущим или возможным в будущем ответом, связанным с специфичными действиями над конкретным инстансом ресурса (или ресусров). Если это так, то при формировании заголовков для конкретного инстанса (или в результирующих заголовках, отталкивающихся от 226 ответа и других инстансов) нужно руководствоваться частью 13.5.3 спецификации HTTP/1.1.

Запрос обязан содержать в A-IM заголовке перечень как минимм одной манипуляции с инстансом. Ответ обязан содержать ETag заголовк с тегом для конкретного инстанса.

Ответ переданный с 226 кодом может быть закеширован и использован в ответах, актуальность которых регулируется Cache-Control заголовком, а также требованиями, которые описаны в секции 10.6.

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

Wikipedia

Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

3xx: Redirect

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

Замечание: предыдущая версия спецификации допускала максимум 5 редиректов. Разработчики должны иметь это ввиду.

Wikipedia

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT). Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

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

Если это не был HEAD запрос, ответ СЛЕДУЕТ включить объект, содержащий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется по типу данных приведеных в Content-Type поля заголовка. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако, эта спецификация не определяет никакого стандарта для автоматического выбора.

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

Wikipedia

По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

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

Новый постоянный URI должен быть передан в Location заголовке в ответе. Если запрос был не HEAD — в ответе должно содержаться краткое описание того, что адрес изменился с ссылкой на новый адрес. Данная информация должна быть предоставлена в виде HTML.

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

Замечание: Некоторые HTTP/1.0 клиенты, после автоматического редиректа POST запроса, после принятия 301 статуса, ошибочно преобразуют его в GET запрос.

Wikipedia

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

Запрошенный ресурс временно находится под другим URI. Так как переадресация может быть изменена в любой момент, клиенту СЛЕДУЕТ продолжать использовать тот же самый URI для будущих запросов. Этот ответ является кэшируемы если не было назначено Cache-Control или Expires поля заголовка.

Временныей URI должен быть передан в Location заголовке в ответ на запрос. В случае, если запрос был не HEAD — в ответе должно содержаться упоминание о новом URI в гипертекстовом представлении.

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

Замечание: RFC 1945 и RFC 2068 описывают, что клиенту не допустимо изменять метод исходного запроса при редиректе. Тем не менее, большинство существующих реализаций User Agent обрабатывает 302 как будто был передан ответ 303, выполняя GET для адреса, переданного в Location, независимо от исходного метода запроса. Статусы 303 и 307 были добавлены для серверов, которым необходимо однозначно понимать, какой вид реакции ожидать от клиента.

Wikipedia

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

Документ по запрошенному аресу может быть найден по другому URI и должен быть найден с использоваием GET запроса. Этот метод существует прежде всего, чтобы позволить выход из POST-активированной сценария, используя перенаправление агента пользователя на указанный ресурс. Новый URI не является заменой для исходного адреса. 303 статуст не должен быть закеширован, однако ресурс, куда будет выполнен редирект — может быть закеширован.

Новый URI должен быть передан посредством Location в ответе. В случае, если исходный запрос был отличен от HEAD — в ответе должна содержаться ссылка на новый URI в гипертекстовом формате.

Замечание: Многие агенты, до HTTP/1.1 не понимают статуса 303. Когда взаимодействие с такими клиентами является проблемой, код состояния 302 может быть использован вместо 303, так как большинство агентов реагируют на ответ 302, также как на 303.

Wikipedia

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска.

Введено в HTTP/1.1

Если клиент выполнил условный запрос GET и доступ разрешен, но документ не был изменен, сервер должен ответить, используя этот код состояния. Ответ 304 НЕ ДОЛЖЕН содержать тела сообщения, и, таким образом, всегда завершается первой пустой строкой после полей заголовка.

Ответ должен содержать следующие заголовки:

  • Дата, если ее отсутствие не требует раздел 14.18.1

Если сервер подчиняется этим правилам, и прокси-серверы и клиенты добавят свои собственные Даты к любому ответу, полученным без Даты (как уже указано [RFC 2068], раздел 14.19), кэши будут работать неправильно.

  • ETag и/или Content-Location, если заголовки передаются с 200 кодом ответа.
  • Expires, Cache-Control, и/или Vary, если значения полей изменились с последнего ответа на предыдущие аналогичные запросы.

Если условный GET запрос использует строгую валидацию на присутствие в кеше ( см 13.3.3) ответ НЕ должен (желательно) включать другие заголовки. В противном случае ответ НЕ должен (обязательно) включать другие заголовки. Это предотовращает нарушение консистентности данных в кеше и модификации заголовков.

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

Если кэш использует полученный 304 ответ для обновления кэша, кэш ДОЛЖЕН обновить запись, чтобы отразить любые новые значения полей, переданных в ответ.

Wikipedia

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

Используется ля условных GET запросов для снижения нагрузки на сеть. Если используется, то обязательны для передачи Data, Content-Location, ETag заголовки. Тело ответа при этом статусе не передается.

Доступ к запрошенному ресурсу ДОЛЖЕН быть осуществлен через прокси, указанный в поле Location. Поле Location предоставляет URI прокси. Ожидается, что получатель повторит этот запрос с помощью прокси. Ответ 305 может генерировать ТОЛЬКО серверами-источниками.


Заметьте: в спецификации RFC 2068 однозначно не сказано, что ответ 305 предназначен для перенаправления единственного запроса, и что он должен генерироваться только сервером-источником. Упущение этих ограничений вызвало ряд значительных последствий для безопасности.

Wikipedia

Многие HTTP клиенты (такие, как Mozilla и Internet Explorer) обрабатывают этот статус некорректно прежде всего из соображений безопасности.

Статус 306 использовался в предыдущих версиях спецификации, но больше не используется и код зарезервирован.

Wikipedia

Больше не используется. Раньше обозначал «последующие запросы должны использовать указанный прокси-сервер»

Запрошенный ресурс временно находится по другому URI. Так как переадресация может быть изменена по какой-либо причине, клиенту следует продолжить использовать Request-URI для последующих запросов. Этот ответ можно закешировать только в том случае, если это обозначено в заголовках Cache-Control или Expires.

Временный URI СЛЕДУЕТ передать в ответе в поле Location. Если метод запроса не HEAD, в сущность запроса СЛЕДУЕТ включить короткую гипертекстовую заметку со ссылкой на новый (новые) URI, поскольку многие агенты, использующие более ранние протоколы, чем HTTP/1.1, не понимают статус 307. Поэтому пометке СЛЕДУЕТ содержать информацию, необходиную для пользователя, чтобы повторить запрос на новый URI.

Если статус 307 получен в ответ на запрос, метод которого отличается от GET или HEAD, агент НЕ ДОЛЖЕН автоматически перенаправлять запрос до тех пор, пока он не будет подтвержден пользователем, поскольку это может изменить условия, из-за которых и был сгенерирован этот запрос.

Wikipedia

В этом случае запрос следует повторить на другой URI; как бы то ни было, последующие запросы могут использовать первоначальный URI. В противоположность статусу 302, метод запроса не должен изменяться, когда первоначальный запрос пересоздается. Например, POST-запрос нужно продублировать другим POST-запросом.

Нужно повторить запрос на другой адрес без изменения применяемого метода.

Wikipedia

Этот и все последующие запросы нужно повторить на другой URI. 307 и 308, как было предложено, схожи в поведении с 302 и 301, но не требуют замены HTTP метода. Таким образом, например, отправку формы на «постоянно перенаправленный» ресурс можно продолжать без проблем.

4xx: Client Error

Класс кодов 4xx предназначен для определения ошибок, которые произошли на стороне клиента. Кроме случая, когда метод запроса был HEAD, серверу СЛЕДУЕТ включить в ответ сущность, которая содержит в себе объяснение ситуации, которая привела к ошибке, и является ли это временным или постоянным условием. Эти коды применимы к любому методу запроса. Пользовательским агентам СЛЕДУЕТ отображать пользователю включенную в такой ответ сущность.

Если клиент передает данные, то серверу, использующему TCP СЛЕДУЕТ убедиться, что клиент подтверждает отправку пакетов, содержащих ответ, до того, как сервер закроет соединение. Если клиент продолжит отправку данных после того, как сервер закрыл соединение, TCP стек сервера отправит пакет с флагом сброса (TCP reset packet), который может уничтожить клиентские данные, находящиеся в неподтвержденных входных буферах, до того, как они будут прочитаны и обработаны HTTP приложением.

Wikipedia

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

Запрос не удалось обработать из-за синтаксической ошибки. Клиенту НЕ СЛЕДУЕТ повторять такой запрос без изменений.

Wikipedia

Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

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

Запрос требует аунтефикации пользователя. Ответ должен содердать WWW-Authenticate заголовок (раздел 14.47). Клиент может повторить запрос с корректным Authorization заголовком (раздел 14.8). Если запрос уже содержит информацию для авторизации, в таком случае 401 код ответа показывает, что авторизация была отклонена. Если 401, содержит тот же самый вызов, как и предшествующий ответ, а агент пользователя уже делал попытку аутентификации по крайней мере один раз, то СЛЕДУЕТ показать пользователю объект, который был дан в ответе, так как этот объект может включать соответствующую диагностическую информацию. Аутентификации доступа HTTP объясняется в «HTTP-аутентификации: Basic и Digest Authentication Access».

Wikipedia

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

Код используется для пропущенного или не корректного токена аунтефикации.

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

Wikipedia

Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

Сервер понял запрос, но отказывается его обрабатывать. Авторизация не поможет и этот запрос НЕ СЛЕДУЕТ повторять. Если метод запросы был HEAD и сервер хочет указать причину, почему запрос не был обработан, то ему СЛЕДУЕТ включить в ответ сообщение с объяснением. Если сервер не хочет, чтобы эта информация была доступна клиенту, вместо кода 403 можно использовать 404.

Wikipedia

Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

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

Сервер не нашел по указанному URI никаких ресурсов. Нет никаких указаний о том, постоянное это состояние или нет. СЛЕДУЕТ использовать статус 410 (Gone), если серверу известно, что старый ресурс недоступен постоянно и у него нет адреса пересылки. Этот статус часто используют тогда, когда сервер не хочет обнаруживать истинную причину того, почему он не обработал запрос, или если нельзя применить никакой другой запрос.

Wikipedia

Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

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

Выполнение метода, определенного в запросе, не разрешено для ресурса, идентифицированного конкретным адресом. Ответ должен содержать Allow заголовок, со списком разрешенных методов для запрашиваемого ресурса.

Wikipedia

Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

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

Если глагол запроса был не HEAD, в ответ СЛЕДУЕТ включить список доступных характеристик сущности и их места расположения, из которых пользователь или агент пользователя может выбрать наиболее приемлемый вариант. Формат сущности указан в заголовке Content-Type. В зависимости от формата и возможнотей агента пользователя, выбор наиболее приемлемого варианта МОЖЕТ происходть автоматически. Как бы то ни было, эта спецификация не определяет каких-либо стандартов для автоматической выборки.

Заметьте: Сервера HTTP/1.1 могут возвращать ответы, неприемлемые для запроса с указанным заголовками. В некоторых случаях предпочтительнее возвращать статус 406. Такое поведение поощряет пользователя проверять заголовки запроса и определять, является ли запрос приемлемым.

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

Wikipedia

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

Этот код, аналогичен 401 (Unauthorized), но отражает то, что пользователь должен сначала авторизироваться через прокси. Прокси сервер должен вернуть Proxy-Authenticate заголовок (раздел 14.33), содаржащй запрос ресурса. Клиент может повторить запрос вместе с Proxy-Authenticate заголовком (раздел 14.34). HTTP доступ рассмотрен в «HTTP Authentication: Basic and Digest Access Authentication»

Wikipedia

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

Клиент не предоставил запрос за то время, пока сервер был готов его ждать. Клиент МОЖЕТ повторить запрос без изменений в любое время.

Wikipedia

Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

Запрос нельзя обработать из-за конфликта в текущем состоянии ресурса. Этот код разрешается использовать только в тех случаях, когда ожидается, что пользователь может самостоятельно разрешить этот конфликт и повторить запрос. В тело ответа СЛЕДУЕТ включить достаточное количество информации для того, чтобы пользователь смог понять причину конфликта. В идеале ответ должет содержать такую информацию, которая поможет пользователю или его агенту исправить проблему. Однако, это не всегда возможно и это не обязательно.

Как правило, конфликты происходят во время PUT-запроса. Например, во время использования версионирования, если сущность, к которой обращаются методом PUT, содержить изменения, конфликтующие с теми, что были сделаны ранее третьей стороной, серверу следует использовать ответ 409, чтобы дать понять пользователю, что этот запрос нельзя завершить. В этом случае, в ответной сущности должен содержаться список изменений между двумя версиями в формате, который указан в поле заголовка Content-Type.

Wikipedia

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

Whenever a resource conflict would be caused by fulfilling the request. Duplicate entries and deleting root objects when cascade-delete is not supported are a couple of examples.

Требуемый ресурс больше не доступен на сервере и адрес его расположения не известен. Предполагается, что это состояние постоянно. Клиентам с возможностью редактирования ссылки СЛЕДУЕТ удалить ссылки на запрошенный URL после подтверждения. Если сервер не знает, или у него нет возможности определить, постоянно это состояние или нет, СЛЕДУЕТ использовать статус 404 (Not Found). Этот ответ можно кешировать до тех пор, пока не появится другая информация.

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

Wikipedia

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

Сервер отказывается принять запрос без указания Content-Length. Клиент МОЖЕТ повторить запрос, если добавит корректное значение в поле заголовка Content-Length, которое содержит длину тела сообщения в сообщении запроса.

Wikipedia

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

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

Wikipedia

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

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

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

Wikipedia

Тело запроса больше, чем сервер может обработать.

Cервер не может обработать запрос из-за слишком длинного указанного URL. Эту редкую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST, когда клиент попадает в «черную дыру» редиректов (например, когда префикс URI указывает на свое же окончание), или когда сервер подвергается атаке со стороны клиента, который пытается использовать дыры в безопасности, которые встречаются на серверах с фиксированной длинной буфера для чтения или обработки Request-URI.

Wikipedia

Укзанный URI был слишком длинным и сервер не смог его обработать.

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

Wikipedia

По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Например, клиент пытается загрузить изображение в формате image/svg+xml, а сервер ожидает другой формат.

Серверу следует вернуть ответ с этим кодом, если запрос содержал поле заголовка Range и ни одно из его значений не совпало с размером выбранного ресурса, при этом в запросе не было поля заголовка If-Range. (Для байтовых диапазонов (byte-range) это означает, что значение first-byte-pos в спецификации byte-range-spec было больше, чем фактический размер выбранного ресурса.)

Когда этот статус возвращается в ответ на запрос с указанием диапазона запрашиваемых байт (byte-range requests), в ответ СЛЕДУЕТ включить поле заголовка сущности Content-Range, в котором указать фактический размер ресурса (см. секцию 14.16). Этот ответ НЕЛЬЗЯ использовать при передаче типа multipart/byteranges.

Wikipedia

Клиент запросил часть файла, но сервер не может ее передать. Например, если клаент запросил часть файла, которая находится за пределами конца файла.

Сервер не может удовлетворить значению поля Expect заголовка запроса (см. секцию 14.20), или, если сервер — прокси, у него есть однозначное доказательство того, что сервер следующего уровня не сможет удовлетворить этот запрос.

Wikipedia

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

Wikipedia

Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами. Как бы то ни было, реализации существуют. HTTP сервер Nginx в своей конфигурации использует этот код для имитации goto-подобного поведения.

Wikipedia

Возвращается Twitter Search и Trends API, когда клиент отправляет слишком много запросов. Вероятно, номер этого кода — отсылка к культуре употребления марихуаны Другие сервисы используют вместо этого кода статус 429 Too Many Requests.

Ответ 422 (Unprocessable Entity) означает, что сервер понимает указанный вид данных, (следовательно, статус 415(Unsupported Media Type) не подходит), и синтаксис запроса корректен (поэтому статус 400 (Bad Request) не подходит), но содержащиеся в запросе инструкции нельзя выполнитью. Например, эта ошибка может возникнуть, если тело запроса было синтаксически правильным, но содержало семантическую ошибку.

Wikipedia

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

Статус 423 значит, что целевой ресурс недоступен для указанного метода. Этот ответ СЛЕДУЕТ содержать соответствующее предусловие или постусловие, например ‘lock-token-submitted’ или ‘no-conflicting-lock’

Wikipedia

Wелевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

Код 424 (Failed Dependency) значит, что метод невозможно применить к ресурсе, потому что запрошенное действие зависело от другого действия, выполнить которое не удалось. Например, если не удалось выполнить команду с методом PROPPATCH, то, как минимум, все остальные запросы завершатся со статусом 424 (Failed Dependency).

Wikipedia

Не удалось завершить запрос из-за ошибок к предыдущем запросе. (например, PROPPATCH)

Slein, J., Whitehead, E.J., et al., «WebDAV Advanced Collections Protocol», Work In Progress.

Wikipedia

Defined in drafts of «WebDAV Advanced Collections Protocol», but not present in «Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol».

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

Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status code allows a server to definitively state the precise protocol extensions a given resource must be served with.

Wikipedia

Клиенту следует выбрать другой протокол, например такой, как TLS/1.0.

The 428 status code indicates that the origin server requires the request to be conditional.

Its typical use is to avoid the «lost update» problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict. By requiring requests to be conditional, the server can assure that clients are working with the correct copies.

Responses using this status code SHOULD explain how to resubmit the request successfully.

The 428 status code is optional; clients cannot rely upon its use to prevent «lost update» conflicts.

Wikipedia

The origin server requires the request to be conditional. Intended to prevent «the «lost update» problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.

The 429 status code indicates that the user has sent too many requests in a given amount of time («rate limiting»).


The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.

When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources.

Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.

Wikipedia

The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes.

The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.

It can be used both when the set of request header fields in total are too large, and when a single header field is at fault. In the latter case, the response representation SHOULD specify which header field was too large.

Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps.

Wikipedia

The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.

Wikipedia

Код ответа Nginx. Сервер не вернул информацию и закрыл соединение. (полезно в качестве сдерживающего фактора для вредоносных программ)

Wikipedia

A Microsoft extension. The request should be retried after performing the appropriate action.

Wikipedia

A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.

Доступ к ресурсу закрыт по юридическим причинам. Наиболее близким из существующих является код 403 Forbidden (сервер понял запрос, но отказывается его обработать). Однако в случае цензуры, особенно когда это требование к провайдерам заблокировать доступ к сайту, сервер никак не мог понять запроса — он его даже не получил. Совершенно точно подходит другой код: 305 Use Proxy. Однако такое использование этого кода может не понравиться цензорам. Было предложено несколько вариантов для нового кода, включая «112 Emergency. Censorship in action» и «460 Blocked by Repressive Regime»

Wikipedia

Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту».

Wikipedia

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

5xx: Server Error

Коды ответов, начинающиеся с «5» указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос. Кроме HEAD-запросов, серверу следует включить в ответ сущность, содержащую объяснение ошибки, и является ли это временным или постоянным состоянием. Агентам СЛЕДУЕТ показывать включенную сущность пользователям. Этот код ответа подходит для любых методов запросов.

Wikipedia

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

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

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

Wikipedia

Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.

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

Сервер не поддерживает функциональных возможностей, необходимых для выполнения запроса. Это типичный ответ, когда сервер не понимает метод в запросе и не способен выполнить запрос для ресурса. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

Wikipedia

Серверу либо не известен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос.

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился для выполнения запроса. Появился в HTTP/1.0.

Wikipedia

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера.

Сервер не может обработать запрос из-за временной перегрузки или технических работ. Это временное состояние, из которого сервер выйдет через какое-то время. Если это время извстно, то его МОЖНО передать в заголовке Retry-After. Если заголовок Retry-After передан, то клиенту СЛЕДУЕТ обрабатывать ответ так, как если бы ответом был статус 500.

Замечание: существование кода 503 не обязывает сервер отвечать этим статусом, когда он перегружен. Некоторые сервера просто отвергают соединения.

Wikipedia

Сервер недоступен (из-за перегрузки или технических работ). Обычно это временное состояние.

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

Замечание: Некоторые прокси-сервера возвращают 400 или 500, когда время обраборки DNS запроса превышает установленный таймаут.

Wikipedia

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

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

Wikipedia

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

The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

Wikipedia

В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.

Wikipedia

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

The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with «Depth: infinity». This status indicates that the entire operation failed.

Wikipedia

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

Wikipedia

Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.

The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.

If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information.

Wikipedia

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

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

Ответ должен содержать ссылку на ресурс, на котором пользователь сможет авторизоваться (например с HTML формой)

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

The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.

Responses with the 511 status code MUST NOT be stored by a cache.

The 511 status code is designed to mitigate problems caused by «captive portals» to software (especially non-browser agents) that is expecting a response from the server that a request was made to, not the intervening network infrastructure. It is not intended to encouraged deployment of captive portals, only to limit the damage caused by them.

A network operator wishing to require some authentication, acceptance of terms or other user interaction before granting access usually does so by identifing clients who have not done so («unknown clients») using their MAC addresses.

Unknown clients then have all traffic blocked, except for that on TCP port 80, which is sent to a HTTP server (the «login server») dedicated to «logging in» unknown clients, and of course traffic to the login server itself.

In common use, a response carrying the 511 status code will not come from the origin server indicated in the request’s URL. This presents many security issues; e.g., an attacking intermediary may be inserting cookies into the original domain’s name space, may be observing cookies or HTTP authentication credentials sent from the user agent, and so on.

However, these risks are not unique to the 511 status code; in other words, a captive portal that is not using this status code introduces the same issues.

Also, note that captive portals using this status code on an SSL or TLS connection (commonly, port 443) will generate a certificate error on the client.

Wikipedia

Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585

Wikipedia

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

Wikipedia

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

«Top 10» HTTP код ответа. More REST service-specific information is contained in the entry.

©Андрей Куманяев, 2012-2014. Все права защищены.

Source ©Pearson eCollege, 2012. All rights reserved.

Коды ответов сервера: исчерпывающий список кодов ошибок HTTP

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

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

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

1xx информационные коды

100 Continue Server Code (Продолжение кода сервера)
Код 100 Continue обозначает «нормальную работу». Он указывает, что пользователь сделал качественный запрос, и сервер начал его обрабатывать. Это временный код статуса HTTP, появляющийся лишь в тех отдельных случаях, когда пользователь ожидает окончательный ответ со стороны сервера. Он возникает только после отправки последнего пакета данных.

Когда такой статус-код можно использовать? Это внутренний статус, бывают случаи, когда он не появляется, особенно если пользователю уже удалось получить некоторые данные из сервера. Это что-то похожее на месседж, в котором сообщается, что соединение установилось качественно, и вы можете зайти на сайт. Отправьте данные, но не забудьте закрыть дверь, когда вы закончите (подразумевается код окончательного ответа).

101 Switching Protocols (Переключение протоколов)
Вероятно, это один из простейших кодов сервера. Он означает, что пользователь попросил переключить используемый тип протокола, и веб-сервер согласился на такой шаг.
Когда вы можете его применить? Если осуществляется переход на новую версию HTTP из старой версии протокола. Такой запрос будет выполняться только в том случае, если существует более подходящий протокол (другими словами, если есть более новая версия HTTP).

102 Processing (Обработка)
Поскольку запрос WebDAV (протокол передачи), кроме основного запроса может включать и ряд других подзапросов, подразумевая также и файловые операции, то для его выполнения может потребоваться больше времени.
Когда можно использовать этот код? Он создается для того, чтобы уведомить пользователя и обнулить таймер. Дальше будет активировано ожидание следующей директивы в стандартном режиме, поскольку обработка запросов способна затянуться по времени.

2xx Success (Успех)

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

200 OK
Код состояния 200, наверное, является наиболее популярным, но в то же время очень неприметным в плане использования. Он указывает, что передача данных между сервером и пользователем подошла к завершению, и все прошло так, как должно.
Когда этот код нужно использовать? Постоянно!

201 Created (Создан)
В связи с успешным выполнением запроса создался новый ресурс. К примеру, благодаря запросу юзера сгенерирован такой ранее не существующий веб-ресурс, как новая страница. Исходной сервер настроен так, что обязан создать ресурс еще до отправки 201 кода. Если документ не может быть сгенерирован своевременно, сервер использует в качестве альтернативы код 202 (принят).

202 Accepted (Принят)
Текущий запрос был передан в стадию обработки, но в силу объективных факторов является незавершенным. Запрос к серверу может быть не завершенным, это зависит от факта, успешно ли прошла обработка и не отклонили ли его.

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

203 Non-Authoritative Information (Недостоверная информация)
Серверу удалось полностью обработать запрос, но передаваемые данные не были взяты из первостепенного источника (резервная копия, другой сервер и т. д.) и поэтому информация может быть нерелевантной. Этот код имеет большое сходство с 200 серверным ответом, но указывает, что данные не были получены из источника.

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

204 No Content (Нет контента)
Этот код является ответом сервера, который указывает, что запрос получили и поняли. Но при этом не существует данных, которые могут быть отправлены пользователю. В основном такой код используется для активации скриптов без необходимости внесения изменений в веб-документ. Нужно, чтобы указанный код не содержал основного сообщения, и он должен быть вставлен в первую строку с кодом, которая является доступной сразу после заголовка.

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

205 Reset Content (Сброс контента)
Код обозначает успешную обработку запроса сервером c отсутствующим возвратом контента. В отличие от 204 кода, этот ответ требует, чтобы документ был обновлен.

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

206 Partial Reset (Частичный сброс)
Сервер возвращает только часть контента, которая соответствует заголовку, отправленному клиентом. В основном его используют расширенные инструменты кэширования. Такое бывает, когда пользователь хочет получить лишь небольшую часть контента страницы, а сервер в своем ответе предоставляет данные только для этой части страницы.

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

207 Multi-Status (Мультистатус)
Сервер параллельно предоставляет результаты нескольких независимых операций, которые включаются в тело сообщения в виде XML-документа.

3xx Редирект

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

300 Multiple Choices (Множественный выбор)

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

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

301 Moved Permanently (Удален навсегда)
Это общий запрос пользователя, который означает, что запросы на этот ресурс (а также запросы, которые последуют за ним) следует перенаправить на указанный URL.


Когда он используется? Когда страница потеряна, больше не существует, или линк, ведущий на внешний документ, больше неработоспособен. 301 редирект дает пользователю понять, что запрошенный ресурс переместили. В основном он выполняется с помощью файла .htaccess, который доступен на серверах Apache.

302 Found (Найден)
Этот код говорит пользователю, что местоположение запрашиваемого веб-документа было временно изменено, а код состояния 302 включает данные о новом размещении, к которому пользователь может делать запрос.

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

303 See Other (Смотреть другой)
Он является индикатором того, что искомый ресурс можно найти по URL-адресу, который отличный от того, что указан в запросе. Это не обязательно значит, что ресурс был перемещен. Этот код только предоставляет адрес, который должен запрашиваться при аналогичном ответе.

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

304 Not Modified (Не изменен)
304 означает, что пользователь запрашивает документ / ресурс только тогда, когда он был изменен с момента последних обновлений кеша этого документа.

В каких случаях может применяться этот код? Если ответ сервера сообщает вам, что параметры документа If-Modified-Since или If-Match не изменились со времени генерирования последнего кеша. Тогда нет нужды повторно отправлять ресурс на проверку.

305 Use Proxy (Использовать прокси)
305 код дает понять пользователю, что доступ к запрашиваемому ресурсу осуществим только через прокси-сервер, указанный в ответе.
Когда он показывается? Он часто отображается в связи с мерами безопасности и обеспечивает доступ к запрашиваемым URL-адресам.

306 Switch Proxy (Переключить прокси)
Изначально он означал, что «последующие запросы должны использовать указанный прокси», но в настоящее время не используется.

307 Temporary Redirect (Временный редирект)
Такой код отображается, если открываемый ресурс временно используется для другого URL-адреса, который также содержится в ответе. 307 немного отличается от 302 кода – он является его более конкретной версией.

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

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

Класс ответов 4xx указывает на ошибки на стороне клиента или тот факт, что местоположение никогда (или уже) не существовало.

400 Bad Request (Плохой запрос)
Запрос не обрабатывается правильно в связи с синтаксической ошибкой.
Для чего предназначен этот код? Если пользователь делает запрос на информацию, но при этом пренебрегает протокольными правилами передачи гипертекста. Запрос не следует делать повторно без надлежащих перемен в синтаксисе.

401 Unauthorized (Неавторизирован)
Он имеет отношение к запросу ресурса, который нуждается в авторизации. Код 401 информирует, что предварительную авторизацию отклонили, поскольку переданные пользовательские данные были неверные.

Когда он отображается? В случаях, если пользователь делает запрос и использует при этом некорректные входные данные для авторизации (среди них, логин и пароль).

402 Payment Required (Требуется оплата)
Этот код сервера забронирован на будущее. Но, изначально предполагалось, что такой статус можно будет использовать при расчетах специальными формами электронных денег. Но ему так и не нашлось применения.

Какова сфера применения этого кода? Старый сервис Apple MobileMe сообщал об 402-ошибке, если аккаунт пользователя в MobileMe подозревался в любой форме злоупотреблений его ресурсами. Также видеохостинг Youtube использует этот статус, если некий IP-адрес использует чрезмерно большое количество запросов. Поэтому пользователю приходится ввести CAPTCHA.

403 Forbidden (Запрещен)
Пользователь пробует добиться доступа к веб-ресурсу, на который у него нет прав, а авторизация здесь никак не может помочь.
Что насчет применения этого кода? Он используется, когда сервер может понять запрос, но не разрешает выполнить его, поскольку у клиента имеются ограничения доступа к текущему разделу. Обычно такое наблюдается, если веб-ресурс не предназначен для открытого доступа.

404 Not Found (Не найден)
Большинство пользователей знакомо с 404 ошибкой. Она указывает на то, что искомый ресурс невозможно найти, но в будущем – когда он может появиться там – к нему можно получить доступ. Также здесь разрешаются все следующие обращения от клиента. Но в большом количестве таких случаев используется код редиректа класса 3xx, и пользователь перенаправляется на альтернативный ресурс или местоположение.
Когда демонстрируется этот код? Довольно часто, особенно если страницу удалили или переместили. Часто в таких случаях сервер в автоматическом режиме генерирует доступную страницу с ошибкой 404.

405 Method Not Allowed (Метод не разрешен)
Метод, посредством которого осуществляется запрос к ресурсу, является недоступным. Иными словами, появляется ошибка при попытке использовать функцию в формате GET, тогда как требуется ввод данных через метод POST (либо с помощью метода PUT с веб-документами только для чтения).

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

406 Not Acceptable (Недопустимо)
Запрашиваемый ресурс имеет возможность генерировать только тот контент, который не может использоваться в Accept-хедерах самого запроса. Браузер может обеспечить сервер характеристиками данных, которые будут приниматься из сервера.

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

407 Proxy Authentication Required (Нужна авторизация прокси)
Как и статус-код 401, значение 407 обозначает, что клиенту следует предварительно авторизоваться через прокси-сервер. Для выполнения этого действия и осуществления процесса авторизации, прокси-сервер должен вернуть поле с заголовком Proxy-authenticate, которое отвечает стандартам, предъявляемым сервером.
Когда появляется этот статус-код? В случаях, если сервер «убежден», что запрос данных от клиента является правильным, но получить доступ к веб-ресурсу возможно лишь через авторизацию с помощью прокси-сервера.

408 Request Timeout (Тайм-аут запроса)
Истекло время ожидания сервером ретрансляции от клиента.
Когда такой статус-код применяться? Используя спецификацию W3 HTTP: «Со стороны клиента не поступало запроса в выделенном временном интервале, когда его ждал сервер. Клиент имеет возможность повторить запрос в любое время».

409 Conflict (Конфликт)
Код 409 является индикатором ситуации, когда запрос не выполняется в связи с противоречивостью обращения к веб-документу.
Когда он применятся? Пользователь может получить такой код в случае загрузке файла на веб-сервер, где расположена более поздняя версия этого файла, что приводит к конфликту между версиями в системе управления.

410 Gone (Исчез)
Сервер дает подобный ответ, если раньше ресурс находился по определенному URL-адресу, но его удалили и на данный момент он недоступен. Пользователю не следует несколько раз повторять одно и то же самое обращение.

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

411 Length Required (Требуется длина)
Запрос не указывает длину контента, и запрашивался в совершенной форме.
Когда этот код показывается? Когда браузер не определяет длину запрашиваемого содержимого в заголовке запроса. Сервер не будет принимать запрос без валидного поля заголовка контента.

412 Precondition Failed (Сбой предварительного условия)
Сервер не отвечает на одно из предварительных условий, которые отправитель указал в запросе. Иными словами, один или несколько заголовков запросов были возвращены с атрибутом false.

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

413 Request Entity Too Large (Объект запроса слишком большой)
Код 413 отображается в случаях, когда сервер отказывается обрабатывать запрос, потому что тело запроса слишком велико.
Когда этот код может применяться? При использовании метода POST с контентом, который больше по объему, чем сервер, способен обработать.

414 Request-URL Too Long (URL запроса слишком длинный)
Этот код отображается, когда сервер не может обработать запрос, потому что указанный URL слишком длинный.
Когда этот код может применяться? Когда POST-запрос преобразуется в GET-запрос. POST-запрос поддерживает отправку неограниченного количества данных, объединяя их при обращении к серверу. Однако, если запрос должен быть преобразован в GET-формат, он позволит привязать данные формы к URL-адресу, что даст возможность хранить информацию в больших размерах, чем она была доступна.

415 Unsupported Media-Type (Неподдерживаемый тип)
Код 415 отправляется, для указания, что сервер заметил часть запроса, которая была сделана в неподдерживаемом формате.
Когда отображается такой код? Когда в запросе не указываются какие-либо типы носителей, поддерживаемые ресурсом или сервером. Например, пользователь запрашивает изображение в расширении, которое не поддерживается веб-сервером. Сервер знает, что запрашивалось, но не понимает формат, в котором хотели получить ресурс.

416 Requested Range Not Satisfiable (Диапазон не подходит)
Этот ответ пользователь получает, когда он запрашивает часть ресурса, но в то же время этот фрагмент не может быть предоставлен.
Когда такой статус может применяться? Когда сервер запрашивает байты XXX-YYY ресурса, но ресурс немного меньше, чем указано при обращении.

417 Expectation Failed (Ошибка ожидания)
Такой статусный ответ получают, когда по какой-то причине сервер не удовлетворяет значение поля Expect заголовка запроса.
Когда этот код может применяться? Все абсолютно прозрачно. Когда один из заголовков запросов, заголовок «Expect», получает обращение, на которое сервер не в состоянии ответить.

418 I’m a teapot (Я чайник)
Этот код был создан в 1998 году как одна из традиционных шуток на первое апреля IETF, в RFC 2324, как Hyper Text Coffee Pot Control Protocol и вряд ли он когда-нибудь будет обрабатываться современными HTTP-серверами.

Может ли он использоваться? Конечно нет, все это было -15 лет назад и делалось ради смеха.

422 Unprocessable Entity (Необрабатываемый объект)
Сервер принял запрос и понял его суть, но не может выполнить обращение из-за содержания в нем некоторых семантических ошибок.
Когда используется этот статус-код? Когда на стороне сервера прошло успешное принятие обращения, и сервер способен работать с указанным форматом данных; в теле запроса XML-документ содержит правильные синтаксические конструкции, но также в нем содержится какая-либо логическая ошибка, в связи с которой не представляется возможным управлять ресурсом.

423 Locked (Заблокирован)
Целевой ресурс, указанный в запросе, блокируется в связи с применением к нему определенного метода. Чтобы сделать ресурс доступным, следует разблокировать его или предоставить корректные данные авторизации.
Когда этот код может применяться? Когда ресурс является закрытым, в основном это делается в целях обеспечения безопасности.

424 Failed Dependency (Неудачная зависимость)
424 код сообщает, что выполнение текущего запроса напрямую зависит от успешности другой операции, и если она не будет правильно завершена, то вся обработка запроса остановится.

425 Unordered Collection (Неупорядоченная коллекция)
Код 425 показывается пользователю, когда ресурс определяется одним из черновиков расширенного протокола коллекций WebDAV (Advanced Collections Protocol), но отсутствует в Advanced Collections Protocol и Versioning Ordered Collections Protocol.

426 Upgrade Required (Нужно обновление)
Этот код показывается, когда сервер дает клиенту инструкции по обновлению протокола (переключения на другой или новый протокол) Когда используется код? Обычно, когда в браузере используются устаревшие протоколы.

428 Precondition Required (Требуется предпосылка)
Исходный сервер требует указать предварительные условия при обращении. Этот код разработан во избежание конфликтных версий ресурса в тех ситуациях, когда клиент получает (GET) состояние ресурса, изменяет и отправляет (PUT) его обратно на сервер, и в то же время какая-то третья сторона также изменяет местоположение прямо на севере, что приводит к конфликту.

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

429 Too Many Requests (Слишком много запросов)
Этот ответ отправляется, если со стороны клиента поступало слишком большое количество обращений за короткий промежуток времени.
Когда используется этот код? Когда пользователь отправляет слишком много обращений за краткосрочный период.

431 Request Header Fields Too Large (Поля заголовков слишком большие)
Появляется, когда сервер не намерен совершать обработку запроса, поскольку какое-нибудь из полей заголовка (или все существующие поля) слишком велики.
Когда он применяется? Базово, когда заголовок запроса, поступающий от юзера больше, чем способен обработать сервер. Обращение можно повторить после того, как поля заголовка в нем будут сокращены.

444 No Response (Нет ответа)
Используется в лог-файлах сервера Nginx, для указания, что сервер не передавал информацию обратно пользователю и закрыл соединение.
Какова сфера применения кода? В основном он использовался как инструмент защиты от вредоносного софта.

449 Retry With (Microsoft) (Повторить попытку)
Расширение Microsoft, которое указывает, что запрос следует повторить после завершения соответствующего действия.
Когда этот код может применяться? Он часто создается, когда настройки запроса не соответствуют тому, что способен проверить сервер.

450 Blocked by Windows Parental Controls – Microsoft (Заблокировано родительским контролем Windows)
Расширение Microsoft. Эта ошибка возникает, когда в параметрах родительского контроля Windows установлена блокировка доступа к некоторым веб-документам.
Когда применяется 450 код? В случае, если родители (зная об этой функции) прибегают к использованию родительского контроля, а id-access запросил доступ к заблокированному ресурсу.

451 Unavailable For Legal Reasons (Недоступен по юридическим причинам)
Новый HTTP-код статуса для ресурсов, которые заблокированы по юридическим соображениям. Применяется, чтобы указать, что доступ к нужному веб-ресурсу заблокировали по юридическим мотивам: например, посредством цензуры или правительства.

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

Коды 5xx выделены для случаев неудачной работы на стороне сервера.
Эти ответы сервера часто отображаются, когда запросы пользователя не могут быть обработаны сервером по той или иной причине. Сервер должен иметь специальное сообщение для браузера, которое должно отображаться пользователю – оно уведомляет, что сервер (по какому-либо поводу) не в состоянии произвести обработку запроса.

500 Internal Server Error (Внутренняя ошибка сервера)
Этот статус сообщает о внутренней ошибке сервера, которая не совпадает с другими ошибками того же класса.
Этот код используется, если ресурс или ссылка создается на сервере (например, календарь в системе резервирования), который технически не существует как ссылка или доступный ресурс, но пользователь видите их как ссылки.

501 Not Implemented (Не поддерживается)
Сервер либо не понимает метод запроса, либо не поддерживает инструкции, нужные, чтобы обработать обращение.
Вы можете столкнуться с указанным кодом 501, когда сервер не имеет поддержки стандартных протоколов запросов, среди которых GET, OPTIONS, HEAD, POST и т. д.

502 Bad Gateway (Плохой шлюз)
Пользователь увидит 502 код, если сервер, работает в качестве шлюза или прокси-сервера, и он получил недопустимый ответ от сервера верхнего уровня.
Когда используется подобный код? Обычно, когда сервер высшего уровня и прокси / шлюз не согласованы с протоколами, которые представленными в обращении. Как результат появляется ошибка обмена данных.

503 Server Unavailable (Сервер недоступен)
Код 503 означает, что возникли технические причины, из-за которых сервер на определенное время не способен обработать набор данных.
Его допустимо использовать в случаях, когда на сайт есть повышенный спрос, но у сервера нет возможности обрабатывать все входящие запросы.

504 Gateway Timeout (Тайм-аут шлюза)
Сервер как шлюз или прокси-сервер не дождался ответа от вышестоящего сервера, чтобы завершить текущий запрос.
Когда этот код может применяться? Когда прокси или шлюз используют как канал передачи данных, а два сервера при этом ожидают на ответ.

505 HTTP Version Not Supported (Версия HTTP не поддерживается)
Сервер не поддерживает версию HTTP протокола, обозначенную при обращении к нему.
Где используется такой код? В тех случаях, которые были указаны выше! Если HTTP протокол более старый, чем нужно серверу, и, как следствие, он не поддерживается.

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

507 Insufficient Storage (Недостаточно места)
Ошибка 507 имеет место, когда сервер не может разместить данные, поскольку для текущего запроса недостаточно пространства.
Этот код может быть применен, когда сервер загружен в полном объеме, а пользователь запрашивает ресурс, который уже имеется в наличии. Трудность здесь заключается в том, что на сервере нет места для хранения отправленных в запросе данных, чтобы отправить запрашиваемый ресурс.

509 Bandwidth Limit Exceeded (Превышена пропускная способность)
Этот код ответа используется, когда веб-сайт лимитирует ограничение трафика, предназначенное для него.
Когда используется этот статус? Когда Apache запускает правильное расширение, а ISP имеет пропускную способность, которая может быть скоро превышена. Здесь имеется несколько форм ограничения.

510 Not Extended (Нет расширения)
Код 510 появляется, когда на сервере нет расширения, которое хочет использовать клиент. Когда этот код появляется? Когда сервер требует больше данных в запросе.

511 Network Authentication Required (Требуется аутентификация сети)
Этот статус-код демонстрируется, если клиенту следует сначала авторизоваться в сети, к примеру, необходимо ввести пароль для платного доступа в сеть Интернет.
Когда используется этот код? Когда пользователь сначала должен дать свое согласие на условия использования, прежде чем он получит доступ к Интернету (например, к Wi-Fi точке доступа).

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

Когда браузер для доступа браузера на страницу просмотра веб отправляет запрос на сервер, где веб. Когда браузер получает и отображает первую страницу, сервер, на котором эта страница будет возвращать (заголовок сервера) в заголовок HTTP код состояния для ответа на запрос содержит браузер.

Коды состояния HTTP на английском языке для кода HTTP статуса.

Вот некоторые коды состояния общих HTTP:

  • 200— запрос был успешным
  • 301— ресурсы (веб-страниц и т.д.) постоянно переносится на другой URL
  • 404 — ресурсы (веб-страниц и т.д.) запросили, не существует
  • 500 — Внутренняя ошибка сервера

HTTP код классификации состояния

Код состояния HTTP состоит из трех десятичных цифр, первое десятичное число определяет тип кодов состояния, последние две цифры не классифицированы эффект. код состояния HTTP делится на пять типов:

Http коды 3xx. Полное руководство по кодам статуса HTTP. Работа с кодами состояния HTTP

Введение новых кодов должно производиться только после согласования с IETF . Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With . Так же упоминается пояснительная фраза «Reply With» в спецификации по WebDAV в Microsoft Developer Network , введённый Microsoft и 509 Bandwidth Limit Exceeded , введённый в cPanel . Компания Google предложила комитету IETF использовать HTTP-код 451 для уведомления о преднамеренном блокировании порталов .

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

Веб-сервер Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды, записывая их через точку после основного. При этом в ответах от сервера данный подкод не размещается — он нужен администратору сервера чтобы тот мог более точно определять источники проблем.

Обзорный список

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

  • (информационные):
  • (успешно):
  • (перенаправление):
  • (ошибка клиента):
  • (ошибка сервера):

Описание кодов

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

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

  • 100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
  • 101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update . Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
  • 102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV .

Успех

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

Перенаправление

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

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT) . Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302 . Изменять метод нужно только если сервер ответил 303 . В остальных случаях следующий запрос производить с исходным методом.

Поведение клиентов при различных перенаправлениях описано в таблице:

  • 300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME , по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
  • 301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
  • 302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location . Этот код может быть использован, например, при управляемом сервером согласовании содержимого . Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
  • 303 See Other — документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307 -ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET . Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST , включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303 , указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
  • 304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET , использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
  • 305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер , URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
  • 306 (зарезервировано) — использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
  • 307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

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

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

  • 400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
  • 401 Unauthorized — запрос требует идентификации пользователя. Сервер должен запросить имя и пароль у пользователя, а тот передаст их в заголовке WWW-Authenticate в следующем запросе. Если были указаны неверные данные, то сервер снова вернёт этот же статус. Появился в HTTP/1.0.
  • 402 Payment Required — предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

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

  • 403 Forbidden — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ или при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения . В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
  • 404 Not Found — самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код . Ответ 404 может использоваться вместо , если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
  • 405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow , разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код . Появился в HTTP/1.1.
  • 406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD , то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
  • 407 Proxy Authentication Required — ответ аналогичен коду за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
  • 408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT . В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потеря связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
  • 409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT .Появился в HTTP/1.1.
  • 410 Gone — такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код . Появился в HTTP/1.1.
  • 411 Length Required — для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT . Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
  • 412 Precondition Failed — возвращается, если ни одно из условных полей заголовка [неизвестный термин ] запроса не было выполнено. Появился в HTTP/1.1.
  • 413 Request Entity Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
  • 414 Request-URL Too Long — сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET , а не POST . Появился в HTTP/1.1.
  • 415 Unsupported Media Type — по каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
  • 416 Requested Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range . Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges . Введено в RFC 2616 (обновление HTTP/1.1).
  • 417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
  • 422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML -документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV .
  • 423 Locked — целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV .
  • 424 Failed Dependency — реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV .
  • 425 Unordered Collection — посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного [уточнить ] . Введено в черновике по WebDAV Advanced Collections Protocol .
  • 426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection . Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
  • 449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request . Введено корпорацией Microsoft для WebDAV . В настоящий момент как минимум используется программой Microsoft Money .
  • 456 Unrecoverable Error — возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV .

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

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

См. также

Примечания

Ссылки

Основные документы по протоколу HTTP (по убыванию даты публикации):

  • Hypertext Transfer Protocol (HTTP) Status Code Registry (англ.) . IANA (17 октября 2007). — реестр кодов состояния HTTP. Архивировано из первоисточника 17 февраля 2012. Проверено 30 июля 2009.
  • RFC 2616 Draft standard « » (англ.) (русск. ); IETF , июнь 1999; Fielding Roy (англ.) русск. (UC Irvine (англ.) русск. ), Gettys Jim (англ.) русск. (Compaq /W3C), Mogul J. (Compaq), Frystyk Henrik (англ.) русск. (MIT /W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C /MIT) — обновление протокола HTTP версии 1.1.
  • RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1 » (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1» ); IETF , январь 1997; Fielding Roy (англ.) русск. (UC Irvine (англ.) русск. ), Gettys Jim (англ.) русск. (DEC), Mogul J. (DEC), Frystyk Henrik (англ.) русск. (MIT /LCS), Berners-Lee Tim (MIT /LCS) — ранняя спецификация по HTTP версии 1.1.
  • RFC 1945 Informational «

Во время запроса информации с удаленного веб сервера может возникнуть ошибка, тогда веб-сервер посылает в ответ код ошибки HTTP . Например 404 – Not Found (ресурс не найден).
Коды состояния HTTP состоят из трех цифр от 100 и до 510. Они делятся на следующие группы:

  1. Информационные (100-105)
  2. Успешные (200-226)
  3. Перенаправление (300-307)
  4. Ошибка клиента (400-499)
  5. Ошибка сервера (500-510)


Введите в поле ниже интересующий Вас трех символьный код и получите его описание:

Continue Cервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

Switching Protocols Сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовкаUpdate. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.

Processing Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

ОК Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

Created В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется[источник не указан 336 дней] ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.

Accepted Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

Non-Authoritative Information Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

No Content Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

Reset Content Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

Partial Content Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)

Multi-Status Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

IM Used Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

Multiple Choices По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

Moved Permanently Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

Found, Moved Temporarily Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, приуправляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

See Other Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

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

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

(зарезервировано) использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

Temporary Redirect Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

Bad Request Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

Unauthorized Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

Payment Required Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговыхкомпаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

Forbidden Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам.htaccess или.htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

Not Found Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

Method Not Allowed Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

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

Proxy Authentication Required Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

Request Timeout Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потеря связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

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

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

Length Required Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

Precondition Failed Возвращается, если ни одно из условных полей заголовка[неизвестный термин] запроса не было выполнено. Появился в HTTP/1.1.

Request Entity Too Large Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

Request-URL Too Long Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

Unsupported Media Type По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

Requested Range Not Satisfiabl В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges[источник не указан 336 дней]. Введено в RFC 2616 (обновление HTTP/1.1).

Expectation Failed По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

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

Locked Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

Failed Dependency Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

Unordered Collection — Посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного[уточнить]. Введено в черновике по WebDAV Advanced Collections Protocol.

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

Retry With Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

Unrecoverable Error Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных[источник не указан 336 дней]. Введено корпорацией Microsoftдля WebDAV.

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

HTTP коды 1хх – информационные коды. HTTP коды 2хх – успешные коды. HTTP код 3хх – коды перенаправления. HTTP код 4хх – коды ошибок клиента. HTTP код 5хх – коды ошибок сервера.

Если вы хотите узнать , обратитесь к .Код состояния – это элемент ответа , который представляет собой три цифры, первая цифра показывает к какому классу состояния относится тот или иной . В HTTP насчитывают всего пять классов кодов состояний : 1хх, 2хх, 3хх, 4хх, 5хх. HTTP коды состояний расширяемы, любой разработчик сервера может добавлять свои коды. Каждый код состояния очень тесно связан с : если метод – это элемент , то код состояния это сервера, который означает то, как сервер понял запрос.

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

HTTP
  • Упорство
  • компрессия
  • HTTPS
  • QUIC
методы запроса
  • ОПЦИИ
  • ПОЛУЧИТЬ
  • ГОЛОВА
  • СООБЩЕНИЕ
  • ПОЛОЖИЛ
  • УДАЛЯТЬ
  • TRACE
  • CONNECT
  • PATCH
поля заголовка
  • печенье
  • ETag
  • Место нахождения
  • HTTP реферер
  • DNT
  • X-Forwarded-For
коды состояния
  • 301 перемещена Постоянно
  • 302 Найдено
  • 303 See Other
  • 403 Forbidden
  • 404 Не Найдено
  • 451 Недоступен по юридическим причинам
Методы контроля доступа безопасности
  • Базовая аутентификация доступа
  • аутентификация доступа Дайджест
Номер HTTP код состояния и его описание
1 HTTP коды состояний 1xx: Такой код состояния сервер высылает в том случае, когда запрос получен, но еще не обработан.
2 HTTP коды состояний 2 xx :
Сервер отправит вам такой код в том случае, когда он успешно принял и обработал клиента.
3 HTTP коды состояний 3 xx :
Если вы получили от сервера код состояния, начинающийся на тройку, то это означает, что нужны дополнительные действия, чтобы завершить процесс обработки HTTP запроса.
4 HTTP коды состояний 4 xx :

REST API использует строку состояния в HTTP ответе, чтобы информировать Клиентов о результате запроса.

HTTP определяет 40 стандартных кодов состояния, которые делятся на пять категорий. Ниже выделены только те коды состояния, которые используются в REST API.

Коды состояний в REST

200 (OK)

Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например при:

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

201 (Created — Создано)

REST API отвечает кодом состояния 201 при каждом создании ресурса в коллекции. Также могут быть случаи, когда новый ресурс создается в результате какого-либо действия контроллера, и в этом случае 201 также будет подходящем ответом.

Сервер должен создать ресурс перед тем как вернуть 201 статус. Если это невозможно сделать сразу, тогда сервер должен ответить кодом 202 (Accepted).

202 (Accepted — Принято)

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

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

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

204 (No Content — Нет контента)

Код состояния 204 обычно отправляется в ответ на запрос PUT, POST или DELETE, когда REST API отказывается отправлять обратно любое сообщение о состоянии проделанной работы.

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

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

301 (Moved Permanently — Перемещено навсегда)

Код перенаправления. Указывает, что модель ресурсов REST API была сильно изменена и теперь имеет новый URL. Rest API должен указать новый URI в заголовке ответа Location , и все будущие запросы должны быть направлены на указанный URI.

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

302 (Found — Найдено)

Является распространенным способом выполнить перенаправление на другой URL. HTTP-ответ с этим кодом должен дополнительно предоставит URL-адрес куда перенаправлять в поле заголовка Location. Агенту пользователя (например, браузеру) предлагается в ответе с этим кодом сделать второй запрос на новый URL.

Многие браузеры реализовали этот код таким образом, что нарушили стандарт. Они начали изменять Тип исходного запроса, например с POST на GET. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно определить, какая реакция ожидается от клиента.

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

Код состояния 303 позволяет REST API указать ссылку на ресурс, не заставляя клиента загружать ответ. Вместо этого клиент может отправить GET запрос на URL указанный в заголовке Location .

Ответ 303 не должен кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэшируемым.

304 (Not Modified — Не изменен)

Этот код состояния похож на 204 (Нет контента), так как тело ответа должно быть пустым. Ключевое различие состоит в том, что 204 используется, когда нет ничего для отправки в теле, тогда как 304 используется, когда ресурс не был изменен с версии, указанной заголовками запроса If-Modified-Since или If-None-Match .

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

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

307 (Temporary Redirect — Временный редирект)

Ответ 307 указывает, что rest API не будет обрабатывать запрос клиента. Вместо этого клиент должен повторно отправить запрос на URL, указанный в заголовке Location . Однако в будущих запросах клиент по-прежнему должен использоваться исходный URL.

Rest API может использовать этот код состояния для назначения временного URL запрашиваемому ресурсу.

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

400 (Bad Request — Плохой запрос)

Это общий статус ошибки на стороне Клиента. Используется, когда никакой другой код ошибки 4xx не уместен. Ошибки могут быть как неправильный синтаксис запроса, неверные параметры запроса, запросы вводящие в заблуждение или маршрутизатор и т.д.

Клиент не должен повторять точно такой же запрос.

401 (Unauthorized — Неавторизован)

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

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

403 (Forbidden — Запрещено)

Ошибка 403 указывает, что rest API отказывается выполнять запрос клиента, т.е. Клиент не имеет необходимых разрешений для доступа. Ответ 403 не является случаем, когда нужна авторизация (для ошибки авторизации используется код 401).

Попытка аутентификация не поможет, и повторные запросы не имеют смысла.

404 (Not Found — Не найдено)

Указывает, что rest API не может сопоставить URL клиента с ресурсом, но этот URL может быть доступен в будущем. Последующие запросы клиента допустимы.

404 не указывает, является ли состояние временным или постоянным. Для указания постоянного состояния используется код 410 (Gone — Пропал) . 410 использоваться, если сервер знает, что старый ресурс постоянно недоступен и более не имеет адреса.

405 (Method Not Allowed — Метод не разрешен)

API выдает ошибку 405, когда клиент пытался использовать HTTP метод, который недопустим для ресурса. Например, указан метод PUT, но такого метода у ресурса нет.

Ответ 405 должен включать Заголовок Allow , в котором перечислены поддерживаемые HTTP методы, например, Allow: GET, POST .

406 (Not Acceptable — Неприемлемый)

API не может генерировать предпочитаемые клиентом типы данных, которые указаны в заголовке запроса Accept . Например, запрос клиента на данные в формате application/xml получит ответ 406, если API умеет отдавать данные только в формате application/json .

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

412 (Precondition Failed — Предусловие провалено)

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

415 (Unsupported Media Type — Неподдерживаемый медиа тип)

Сообщение об ошибке 415 указывает, что API не может обработать предоставленный клиентом Тип медиа, как указано в заголовке запроса Content-Type .

Например, запрос клиента содержит данные в формате application/xml , а API готов обработать только application/json . В этом случае клиент получит ответ 415.

Например, клиент загружает изображение как image/svg+xml , но сервер требует, чтобы изображения использовали другой формат.

500 (Internal Server Error — Внутренняя ошибка сервера)


500 — это общий ответ при ошибке в коде rest API. Большинство веб-платформ автоматически отвечают этим кодом состояния, когда при выполнении кода обработчика запроса возникла ошибка.

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

Ответ API 500 — это общий ответ об ошибки на сервере, когда не подходит никакой другой код ошибки.

501 (Not Implemented — Не реализован)

Сервер не распознает метод запроса и не имеет возможности исполнить просьбу клиента. Обычно это подразумевает будущую доступность (например, новая функция API веб-сервиса).

Невозможно без знания ответов сервера.

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

На сегодняшний день выделено 5 основных классов кода ответа:

1xx: Informational (рус. Информационный) — запрос правильно воспринят, но его обработка не завершена.

2xx: Success (рус. Успешно) — запрос правильно воспринят и успешно обработан.

3xx: Redirection (рус. Перенаправление) — коды переадресации на другие страницы.

4xx: Client Error (рус. Ошибка клиента) — ошибка со стороны клиента.

5xx: Server Error (рус. Ошибка сервера) — ошибка со стороны сервера.

А теперь давайте по отдельности разберем некоторые коды состояния IANA.

Ответ сервера 1XX

100 Continue Server Code

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

101 Switching Protocols

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

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

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

Ответ сервера 200 ОК

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

Ответ сервера 301

Также является одним из распространенных кодов ответа. Он сообщает, что запрашиваемая страница по данному адресу более не доступна, а затем происходит перенаправление на другой адрес. 301 редирект может применяться, например, при «переезде» сайта с протокола HTTP на HTTPS (обычно это реализуется через файл.htaccess, доступный на серверах Apache).

Ответ сервера 302

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

Ответ сервера 404

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

Фейковые страницы 404

Большинство вебмастеров не обращает на 404-тые страницы никакого внимания, однако, это может серьезно навредить ранжированию сайта. Парадокс, но страница с сообщением 404 File Not Found далеко не всегда отдает код 404. Такие страницы принято называть «Soft 404». Причины возникновения просты — по каким-то причинам страница отдает код, отличный от 404 и 410 — например, 200. Такое вполне возможно, если страница уже создана, но контента на ней пока нет.

Ответ сервера 500

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

500 Internal Server Error

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

Ответ сервера 502

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

Ответ сервера 550

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

На выходе будет представлена таблица.

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

ВАЖНО! Смешивание MX-записей недопустимо, т.е. в таблице на выдаче должны быть только те MX-записи, которые нужны именно для вашей почты . При необходимости нужно скорректировать записи, исправив ошибки и/или удалив лишнее.

Как получить коды ответа сервера (страницы) через Яндекс

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

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

Теперь переходим в сервис Яндекса (http://webmaster.yandex.ru/server-response.xml), с помощью которого можно посмотреть на сайт глазами робота и проверить скорость ответа сервера в Яндекс панели.

Просто вставляем url-адрес интересующей нас страницы в текстовое поле и нажимаем на кнопку «Проверить». В данном случае мы получили код 200 ОК, свидетельствующий о нормальной работе страницы.

Шаг 2. Проверяем ответ сервера на заведомо несуществующую страницу.

В том же сервисе вводим имя_домена/какая-то_крокозябра

В данном случае мы получили ответ 301 Moved Permanently. Это говорит о том, что адрес страницы указан неверно и происходит переадресация на правильный адрес.

Как еще узнать коды ответа сервера (сайта)?

В качестве альтернативы можно пробить код ответа с помощью сервиса http://mainspy.ru . Работает аналогично сервису Яндекса: вставляем интересующий URL и жмем «Проверить». Код ответа в данном случае находится в самой первой строке:

Bertal, в отличие от Mainspy, позволяет взглянуть на страницу не только глазами Яндекс-бота, но и глазами поисковых роботов Bing и Google, а в качестве бонуса — может эмулировать популярные браузеры. Для удобства взглянем на те же страницы глазами GoogleBot. В данном случае код ответа подсвечен зеленым.

Массовая проверка ответов сервера (сайта) онлайн

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

Dimax.biz — http://backlinks-checker.dimax.biz/tools/proverka_otveta_servera.php — это один из лучших чекеров. Единственный минус — в бесплатном режиме можно делать не более 2 запросов по 50 ссылок каждый. Для более «серьезных» объемов придется воспользоваться платным PRO-тарифом. На выходе мы получаем список, отсортированных по коду ответа. В данном случае в сортировке нет необходимости, т.к. в списке всего 2 адреса, и оба отдают код 200.

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

Как проверить скорость (время) ответа сервера сайта?

Сколько таких сервисов уже развелось — не пересчитать. Рассмотрим некоторые из них.

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

Which Loads Faster

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

Google PageSpeed Insights

Google PageSpeed Insights так же является одним из самых мощных инструментов для измерения скорости работы мобильной и десктопной версии. Оценка производится по 100-бальной шкале. 85 баллов и более — это хороший показатель. Плюс бонусом он выдает рекомендации по улучшению.

Долгий ответ сервера

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

Сложная логика предоставления данных

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

Сами запросы (либо сложные, либо неоптимизированные, либо и то и другое)

Запросы к большому количеству внешних ресурсов

Большое количество исполняемых файлов

Сам веб-сервер долго обрабатывает запрос.

Самые «больные» места производительности сервера:

Используемый веб-сервер (Apache, IIS).

Ряд веб-серверов даже при выдаче статических файлов могут создавать задержки, т.к. они на архитектурном уровне не предназначены для обработки большого количества запросов и из-за этого может быть сообщения что превышено время ожидания ответа от сервера. Поэтому для нормальной работы веб-сервера имеет смысл использовать nginx (причем в связке с Apache, php-fpm, а также остальными серверами приложений для обработки серверных вычислений).

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

Запросы к базе данных.

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

Сложная логика обработки данных.

Третий шаг — упрощение серверной логики. По сути, это просто устранение ненужных операций и профилирование времени выполнения серверных скриптов.

Обращение к сторонним сервисам.

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

Почему скорость ответа веб сервера влияет на продвижение.

Во-первых, потому что скорость загрузки является одним из факторов ранжирования (хоть и не решающим). Google открыто заявляет, что по скорости показа страниц ранжируется менее 1% сайтов. НО…

Во-вторых, если страница слишком долго грузится — пользователь ее просто закроет. Такое поведение пользователя принято называть «отказом». К слову, «отказы» оказывают прямое влияние на позиции в поисковой выдаче. Чем выше скорость загрузки — тем ниже процент отказов и, как следствие, тем выше позиции.

Превышено время ожидания ответа от сервера .

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

Основных же причин сбоя может несколько:

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

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

Что делать для решения?

Если сбой единичен — перезагружаем страницу с помощью комбинации Ctrl+F5. Возможно, потребуется перезагрузить страницу несколько раз. Если не помогло — проверяем подключение к интернету.

1. Некоторые сайты иногда «капризничают». Для динамического IP решение будет простым — перезагрузить роутер через отключение питания.

2. Медленное соединение иногда провоцирует ошибку ERR_CONNECTION_TIMED_OUT. Скорость работы интернета можно проверить через Яндекс-интернетометр . Если скорость слишком низкая — следует обратиться к интернет-провайдеру.

3. Необходимо проверить «Свойства сети» на наличие посторонних DNS-адресов. Если такие адреса имеются — удалить (предварительно на всякий случай переписав их куда-нибудь) и проверить систему на вирусы с помощью установленного на ПК антивирусного ПО — NOD32, Kaspersky, AdwCleaner, MalwareBytes, Dr.Web и т.д. Лучше всего для этих целей использовать Live-загрузчики.

4. Проверить настройки самого роутера. Наиболее часто сбивается параметр MTU. Универсальных рекомендаций по настройке роутера дать невозможно, т.к. это напрямую зависит и от модели роутера, и от интернет-провайдера. Обычно MTU имеет значения 1500, 1460, 1476.

Какое должно быть время ответа сервера?

И сразу же конкретные цифры:

Самая высокая конверсия у страниц, которые полностью загружаются за 1,8 и 2,7 секунды для десктопной и мобильной версий соответственно

Самый низкий показатель отказов у страниц, которые полностью загружаются за 1 и 0.7 секунды для десктопной и мобильной версий соответственно

Данные цифры позаимствованы из исследования Akamai Technologies.

Итак, Вы проверили сайт на скорость загрузки. Но как реагировать на результаты?

Ответы ¶

Когда приложение заканчивает обработку запроса, оно генерирует объект ответа и отправляет его пользователю. Объект ответа содержит такие данные, как HTTP-код состояния, HTTP-заголовки и тело ответа. Конечная цель разработки Web-приложения состоит в создании объектов ответа на различные запросы.

В большинстве случаев вам придется иметь дело с компонентом приложения response , который по умолчанию является экземпляром класса yii\web\Response. Однако Yii также позволяет вам создавать собственные объекты ответа и отправлять их пользователям. Это будет рассмотрено ниже.

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

Код состояния ¶

Первое, что вы делаете при построении ответа, — определяете, был ли успешно обработан запрос. Это реализуется заданием свойству yii\web\Response::statusCode значения, которое может быть одним из валидных HTTP-кодов состояния. Например, чтобы показать, что запрос был успешно обработан, вы можете установить значение кода состояния равным 200:

Однако в большинстве случаев явная установка не требуется так как значение yii\web\Response::statusCode по умолчанию равно 200. Если же вам нужно показать, что запрос не удался, вы можете выбросить соответствующее HTTP-исключение:

Когда обработчик ошибок поймает исключение, он извлечёт код состояния из исключения и назначит его ответу. Исключение yii\web\NotFoundHttpException в коде выше представляет HTTP-код состояния 404. В Yii предопределены следующие HTTP-исключения:

Если в приведённом выше списке нет исключения, которое вы хотите выбросить, вы можете создать его, расширив класс yii\web\HttpException, или выбросить его напрямую с кодом состояния, например:

HTTP-заголовки ¶

Вы можете отправлять HTTP-заголовки, работая с yii\web\Response::headers компонента response :

Info: названия заголовков не чувствительны к регистру символов. Заново зарегистрированные заголовки не отсылаются пользователю до вызова yii\web\Response::send().

Тело ответа ¶

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

Если у вас уже имеется отформатированная строка для тела, вы можете присвоить её свойству yii\web\Response::$content объекта запроса:

Если ваши данные перед отправкой конечным пользователям нужно привести к определённому формату, вам следует установить значения двух свойств: format и data. Свойство format определяет, в каком формате следует возвращать данные из data. Например:

Yii из коробки имеет поддержку следующих форматов, каждый из которых реализован классом форматтера. Вы можете настроить эти форматтеры или добавить новые через свойство yii\web\Response::$formatters.

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

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

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

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

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

Перенаправление браузера ¶

Перенаправление браузера основано на отправке HTTP-заголовка Location . Так как данная возможность широко применяется, Yii имеет средства для её использования.

Вы можете перенаправить браузер пользователя на URL-адрес, вызвав метод yii\web\Response::redirect(). Этот метод использует указанный URL-адрес в качестве значения заголовка Location и возвращает сам объект ответа. В методе действия вы можете вызвать короткую версию этого метода — yii\web\Controller::redirect(). Например:

В приведённом выше коде метод действия возвращает результат redirect() . Как говорилось выше, объект ответа, возвращаемый методом действия, будет использоваться в качестве ответа конечным пользователям.

В коде, находящемся вне методов действий, следует использовать yii\web\Response::redirect() и непосредственно после него — метод yii\web\Response::send(). Так можно быть уверенным, что к ответу не будет добавлено нежелательное содержимое.

Info: По умолчанию метод yii\web\Response::redirect() устанавливает код состояния ответа равным 302, сообщая браузеру, что запрашиваемый ресурс временно находится по другому URI-адресу. Вы можете передать код состояния 301, чтобы сообщить браузеру, что ресурс перемещён навсегда.

Если текущий запрос является AJAX-запросом, отправка заголовка Location не заставит браузер автоматически осуществить перенаправление. Чтобы решить эту задачу, метод yii\web\Response::redirect() устанавливает значение заголовка X-Redirect равным URL для перенаправления. На стороне клиента вы можете написать JavaScript-код для чтения значения этого заголовка и перенаправления браузера соответственно.

Info: Yii поставляется с JavaScript-файлом yii.js , который предоставляет набор часто используемых JavaScript-утилит, включая и перенаправление браузера на основе заголовка X-Redirect . Следовательно, если вы используете этот JavaScript-файл (зарегистрировав пакет ресурсов yii\web\YiiAsset), вам не нужно писать дополнительный код для поддержки AJAX-перенаправления.

Отправка файлов ¶

Как и перенаправление браузера, отправка файлов является ещё одной возможностью, основанной на определённых HTTP-заголовках. Yii предоставляет набор методов для решения различных задач по отправке файлов. Все они поддерживают HTTP-заголовок range.

  • yii\web\Response::sendFile(): отправляет клиенту существующий файл.
  • yii\web\Response::sendContentAsFile(): отправляет клиенту строку как файл.
  • yii\web\Response::sendStreamAsFile(): отправляет клиенту существующий файловый поток как файл.

Эти методы имеют одинаковую сигнатуру и возвращают объект ответа. Если отправляемый файл очень велик, следует использовать yii\web\Response::sendStreamAsFile(), так как он более эффективно использует оперативную память. Следующий пример показывает, как отправить файл в действии контроллера:

При вызове метода отправки файла вне методов действий чтобы быть уверенным, что к ответу не будет добавлено никакое нежелательное содержимое, следует вызвать сразу после него yii\web\Response::send().

Некоторые Web-серверы поддерживают особый режим отправки файлов, который называется X-Sendfile. Идея в том, чтобы перенаправить запрос файла Web-серверу, который отдаст файл пользователю самостоятельно. В результате Web-приложение может завершиться раньше, пока Web-сервер ещё пересылает файл. Чтобы использовать эту возможность, воспользуйтесь методом yii\web\Response::xSendFile(). Далее приведены ссылки на то, как включить X-Sendfile для популярных Web-серверов:

Отправка ответа ¶

Содержимое ответа не отправляется пользователю до вызова метода yii\web\Response::send(). По умолчанию он вызывается автоматически в конце метода yii\base\Application::run(). Однако, чтобы ответ был отправлен немедленно, вы можете вызвать этот метод явно.

Для отправки ответа метод yii\web\Response::send() выполняет следующие шаги:

Повторный вызов yii\web\Response::send() игнорируется. Это означает, что если ответ уже отправлен, то к нему уже ничего не добавить.

Как видно, метод yii\web\Response::send() инициирует несколько полезных событий. Реагируя на эти события, можно настраивать или декорировать ответ.

Page generated on Sat, 09 Nov 2020 19:07:39 +0000

Мастер Йода рекомендует:  Создаем логотип в стиле Web 2.0
Добавить комментарий