Код ошибки 3xx

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

Цель переадресации HTTP

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

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

Давайте подробнее рассмотрим другие причины перенаправления вашей страницы:

• Перенаправление нескольких доменов : постоянные HTTP-перенаправления необходимы для того, чтобы вести интернет-пользователей и поисковые системы в одно и то же место, имея при этом сразу несколько доменных имен.
• Выявление неработающих ссылок : 404 ненайденные страницы могут быть идентифицированы с помощью Google Search Console. Отчет о покрытии предоставит вам подробную информацию обо всех входящих ссылках на сайте, которые необходимо исправить с помощью перенаправления.
• Исправление неработающих URL-адресов : после определения неработающей ссылки вы можете перенаправить трафик на главную страницу. Однако лучшим вариантом является перенаправление каждого неработающего URL-адреса на новую страницу с таким же (аналогичным) содержанием.
• Новое местоположение страницы : если на вашем бывшем веб-сайте есть часто посещаемые страницы, которые имеют высокий рейтинг в поисковой выдаче, перенаправление поможет вам сопоставить этот URL-адрес с новым местоположением. В этом случае вы должны быть уверены, что старые страницы, которые вы использовали для перенаправления, не исчезли.
• Необходимость удаления страницы : создайте переадресацию HTTP для всех страниц, которые нужно удалить, и не пугайтесь и не пугайте посетителей ошибками 404 not found. Перенаправление будет сигнализировать Google или другим поисковым системам, что значение ссылки старых ссылок должно быть присвоено перенаправленным URL-адресам.

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

Подводя итог, Google определяет перенаправление для управления сканированием и индексированием (категория расширенной документации по SEO). Центр поиска Google объясняет переадресацию HTTP как практику выполнения плавного перехода, доступа к странице через несколько URL-адресов, исправления устаревших URL-адресов и отправки пользователей с удаленных страниц на новые, тем самым исключая 404 не найденные ошибки.

Основы веб-протокола

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

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

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

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

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

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

Основные преимущества протоколов HTTP:

• Ответственность за запрос : расширенная схема адресации обеспечивается протоколами HTTP. Все IP-адреса становятся легко узнаваемыми и идентифицируемыми в WWW.
• Улучшено взаимодействие с веб-ресурсами : достигается гибкость и доступность онлайн-ресурсов. HTTP предоставляет возможность загрузки расширений и плагинов. Таким образом отображаются соответствующие данные.

Согласно Hitech Whiz, есть и другие преимущества протокола передачи гипертекста, которые следует учитывать:

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

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

Что такое коды состояния ответа HTTP?

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

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

• Информационный ответ 1xx : этот класс кодов состояния информирует о приеме запроса. Значит, процесс продолжается. Например, 100 = продолжить.
• 2xx успешно : группа этих кодов состояния относится к пониманию и принятию запроса. Например, 200 = ОК.
• Перенаправление 3xx : этот класс кодов состояния HTTP указывает, что для выполнения запроса требуются некоторые специальные действия. Например, 301 = перенаправление.
• Ошибка клиента 4xx : эта категория кодов состояния ответа указывает на то, что запрос не может быть выполнен. Кроме того, это может означать, что в запросе неверный синтаксис. 400 = неверный запрос.
• Ошибка сервера 5xx : этот класс кодов состояния HTTP связан с неудачным ответом сервера, вызванным неудачной обработкой сервера. Например, 500 = внутренняя ошибка.

Стоит отметить, что некоторые коды состояния и ошибки напрямую влияют на SEO. В то время как классы 1xx и 2xx не сильно влияют на поисковую оптимизацию (хотя лучше всего использовать ответ 200), классы 300, 400 и 500 могут негативно повлиять на сканирование и индексирование ваших веб-страниц. Вы всегда должны следить за кодами состояния и ошибками 4xx и 5xx, так как это может быть очень вредным для рейтинга вашего сайта в целом.

Коды HTTP 300, возможно, играют центральную роль для SEO. Этот класс кодов статуса отвечает за передачу всего SEO-значения от ваших старых URL-адресов к новым. Таким образом, необходимо вникнуть в значение каждого 300-уровневого кода (временные или постоянные перенаправления, прокси, множественный выбор и т. Д.).

Полный список кодов состояния HTTP 3xx

Коды состояния HTTP предназначены для перенаправления URL-адресов. Коды уровня 300 обозначают различные типы перенаправлений HTTP. Маркетологи обычно используют коды состояния 3xx для отслеживания и анализа пользовательского опыта, поведения пользователей веб-сайта и эффективности SEO. В DataTracker ресурсы определяют четыре типа переадресаций распределенных по кодам состояния HTTP 300 уровня:

• Такие перенаправления, как 301, 302, 307, указывают на то, что целевому ресурсу был назначен новый URL.
• Перенаправление 300 предлагает несколько вариантов (выбор подходящих веб-ресурсов в соответствии с запросом).
• 303 перенаправление предлагает косвенный ответ на выполненный запрос, если поле Location идентифицирует его.
• Перенаправление 304 обеспечивает перенаправление HTTP на результаты, которые были предварительно кэшированы.

Коды состояния 300 уровня появляются, когда необходимо указать ответ перенаправления от сервера. Другой пример действия класса кода состояния HTTP 3xx — это когда удаленная страница сохраняет свой рейтинг. Кроме того, редиректы пригодятся, когда необходимо исправить неработающий URL.

Например, перенаправление 301 было использовано через PHP для перемещения всего трафика на новую страницу https://eurovps.com:

<?php // Permanent 301 Redirect via PHP

header("HTTP1.1 301 Moved Permanently");

header("Location: https://eurovps.com/");

Таким образом, он сохраняет рейтинг прежнего URL-адреса. Тот же алгоритм можно использовать для исправления неработающих URL-адресов с помощью постоянного редиректа.

Перенаправления не ожидают появления ошибок, связанных с другими кодами ответа. Например, перенаправления не решают проблемы с информационными ответами или ошибками сервера / клиента ( Не реализовано = 501; Плохой шлюз = 502; Непроцессированная сущность = 420).

Давайте подробнее рассмотрим каждый 300-уровневый код, чтобы понять их влияние на SEO и рейтинг веб-сайта. Вам необходимо просмотреть девять кодов состояния 3xx, а также их особенности, функции, преимущества и различия.

300 Multiple Choices

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

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

HTTP/1.1 300 Multiple Choices
Server: curveball/0.3.1
Access-Control-Allow-Headers: Content-Type,User-Agent
Access-Control-Allow-Origin: *
Link: </foo> rel="alternate"
Link: </bar> rel="alternate"
Content-Type: text/html
Location: /foo

Вы можете увидеть /fooи /barв кодировке. Местоположение указывается, когда доступны для выбора оба варианта.

301 Moved Permanently

Еще один код состояния обычно используется в REST API. Основная идея — перенаправление постоянное. Если вам нужно использовать перенаправление на короткое время, редирект 301 не подходит для этой цели. И пользователи Интернета, и поисковые системы переходят на новый URL-адрес с помощью кода состояния 301 HTTP. Наилучший сценарий перенаправления этого типа — когда восстановление прежней страницы не планируется.

Давайте объясним концепцию постоянных перенаправлений HTTP на примере реального случая:

• Страница часто задаваемых вопросов размещена на субдомене ( https://faq.website.com).
• Вы решили переместить свою страницу часто задаваемых вопросов в подпапку ( https://www.website.com/faq/).
• Если поддомен удалить, появится страница 404, которая нанесет вред вашему SEO.
• Пользовательский интерфейс также страдает от этой практики, поэтому перенаправление является обязательным.
• Разместите 301 редирект, чтобы пользователи не могли посещать ваш старый URL.
• Поисковые системы также будут перенаправлены на новую страницу часто задаваемых вопросов.

Рассмотрим еще один пример постоянного перенаправления (301 редирект). Здесь мы видим код состояния 301 HTTP, используемый для перенаправления пользователей и поисковых систем в новое место. Выделенные изменения выделены жирным желтым цветом.

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

• Весь домен может быть перенаправлен на новый веб-сайт. Добавьте после Redirect 301интересующего вас домена:

Redirect 301 /[http://www.website.com/](http://www.website.com/)

• Если вы хотите перенаправить только одну страницу, необходимо указать старый URL после Redirect 301:

Redirect 301 /oldurl/ [http://www.website.com/newurl/](http://www.website.com/newurl/)

Здесь важно упомянуть, что для различных подходов к кодированию требуются разные реализации перенаправления. Например, реализация 301 редиректа с использованием PHP будет выглядеть так:

<?php
header("Location: https://www.website.com/", true, 301);
exit();
?>

Обратите внимание, что JavaScript далеко не оптимален для SEO. Иногда Google неправильно интерпретирует 301 редирект в JavaScript. Если вас интересует постоянное перенаправление, оптимизированное для SEO, лучше выбрать один из перечисленных выше методов.

302 Found

В REST API есть еще один часто используемый код состояния. По сравнению с постоянными перенаправлениями 301, используются 302-уровневые, когда требуются некоторые временные перенаправления. Например, вы знаете об изменениях в этом URL-адресе, который вы скоро перенаправите, или прежняя страница будет восстановлена ​​в какой-то момент. Еще один случай, когда вы должны удалить старую страницу, но вам нужно перенаправить весь трафик и сохранить оценки рейтинга на временном URL-адресе. Среди других причин использования кода состояния 302:

• Миграция на новый, но временный домен
• Изменение структуры сайта (но временно).

Стоит отметить, что реализация 302 редиректа может осуществляться так же, как и для 301-го уровня. Здесь также применима рекомендация избегать кодирования JavaScript в целях оптимизации SEO.

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

303 See Other

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

Код статуса 303 не имеет значения для SEO. Тем не менее, это может помочь повысить удобство использования и реализовать маркетинговые цели, когда можно предложить другой URL-адрес вместо уже посещенного.

303 See Other

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

Давайте подробнее рассмотрим кодирование на примере перенаправления 304. Код состояния указывается в запрошенном методе и URL-адресе.

305 Use Proxy

Этот код состояния HTTP пока не рекомендуется. Некоторые браузеры не позволяют использовать этот тип перенаправления. Например, Mozilla Firefox и Internet Explorer запрещают пользователям выполнять переадресацию 305 по соображениям безопасности. Основное объяснение этой ситуации — единственный прокси-сервер, используемый для обработки запроса и предоставления доступа к веб-ресурсу. Этот подход опасен для некоторых браузеров.

306 Switch Proxy (Unused)

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

307 Temporary Redirect

Этот код состояния HTTP очень похож на код состояния 302. Вот почему метод реализации, необходимый для перенаправления, такой же, как для 301 и 302. Давайте углубимся в разницу между 207 и 302, поскольку оба они относятся к временным перенаправлениям HTTP. Специалисты до сих пор дискутируют на эту тему. Для наших целей есть два мнения о 307 редиректах:

• 307 и 302 редиректы обеспечивают одинаковое временное перемещение контента. При некоторых быстрых изменениях рекомендуется использовать один из этих кодов состояния.
• Есть разница между временными перенаправлениями 302 и 307. Код состояния 302 уровня примечателен изменением метода HTTP. При этом используется 307 редиректов без изменения метода HTTP.

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

308 Permanent Redirect

Этот код состояния считается экспериментальным, но имеет ту же семантику, что и постоянное перенаправление 301. Единственная разница между перенаправлениями 308 и 301 — это доступность изменений метода HTTP. В то время как перенаправления 301 позволяют пользовательским агентам изменять используемые методы HTTP, код состояния 308 подразумевает неизменяемые методы HTTP-запроса для перенаправления.

Код состояния 308 HTTP довольно новый, так как он был введен только в 2015 году. Некоторые браузеры до сих пор не могут распознавать 308 редиректы и показывать пользователям пустые страницы вместо перенаправленных (например, Internet Explorer 11). Вот почему 301 постоянная переадресация будет предпочтительнее из-за лучшей поддержки и удобства для SEO. Код состояния HTTP уровня 308 по-прежнему плохо поддерживается, и поисковые роботы не всегда его распознают.

Значение кода состояния HTTP 3xx для SEO

300-уровневая переадресация важна для сохранения ценности SEO. Если вам нужно перейти с одной старой страницы на другую и вы не хотите терять ее рейтинг, рекомендуется временное или постоянное перенаправление. Чтобы сохранить ссылочный вес и не навредить SEO вашего сайта, когда дело доходит до редизайна или других изменений, вы можете использовать несколько кодов HTTP 300:

• 301 или 308 для постоянной переадресации
• 302, 303, 307 для временных перенаправлений

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

Когда использовать 301 или 302 редирект для SEO

Когда дело доходит до временных и постоянных перенаправлений, коды состояния HTTP 301 и 302 всегда имеют приоритет. Но есть разница между этими кодами HTTP 300. Вот первый сценарий. Вы решили навсегда удалить свой старый сайт. Но этот URL-адрес часто посещался и был высоко оценен поисковыми системами. Есть рекомендация использовать постоянное перенаправление 301, чтобы поддерживать ссылочный вес и рейтинг Google.

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

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

• Вы использовали 301 редирект для временных изменений сайта. В результате Google может исключить ваши старые URL-адреса, необходимые для SEO, из индексации поисковой системой. Вы полностью потеряете ссылочный вес и рейтинг.
• Вы использовали переадресацию 302 для страницы, которая будет удалена навсегда. Поисковые системы продолжают обращать внимание на вашу старую страницу, потому что понимают, что все ваши изменения временные. Таким образом, вы теряете SEO-ценность ваших новых URL-адресов.

Обратите внимание, что код состояния 301 подходит для тематических кластеров. Если вам действительно нужны постоянные перенаправления, не используйте 302. Предотвратите риск потери рейтинга и трафика. Перенаправления 302 заставляют поисковые системы продолжать индексировать ваши старые страницы и не позволяют им передавать ссылочный вес вашим новым. Убедитесь, что вы всегда проверяете точность кода состояния HTTP на своем веб-сайте с помощью специального программного обеспечения, такого как WTOOLS и Redirect Checker.

301 и 302

Постоянные перенаправления

301 имеет более сильную канонизацию для Google. В то же время представитель команды Google Джон Мюллер заявил, что коды состояния HTTP 308 и 301 обеспечивают одинаковые свойства перенаправления и SEO.

Временные перенаправления

Код статуса 307 предпочтительнее для специалистов по SEO. Из-за изменения синтаксиса 302 перенаправлений это может вызвать любое неожиданное поведение. Кроме того, в этом руководстве Rest API указано, что 307 редиректов пригодятся при переносе клиентских запросов на другой хост.

MOZ предлагает 302 редиректа, если по существу невозможно определить, идентифицировали ли поисковые системы страницу как совместимую. Таким образом, любой контент, который временно перемещается на другую страницу, должен быть перенаправлен с помощью кода состояния 302 HTTP. Сканеры отметят изменения, и URL-адрес будет правильно проиндексирован.

Проверка кодов состояния HTTP в рейтинге SE

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

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

1. Откройте раздел Аудит сайта.
2. Укажите веб-сайт, на котором будет запущена проверка.
3. Один из отчетов будет содержать коды состояния HTTP.

Инфографика будет содержать доминирующий класс кода состояния HTTP (1xx, 2xx, 3xx, 4xx, 5xx). Дополнительно в отчете (под основной инфографикой) будет указано количество перенаправлений и отсоединенных страниц.

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

Какие коды 3xx вам действительно нужно знать

Все коды HTTP 300 заслуживают внимания современных представителей бизнеса, которые заинтересованы в хорошей видимости в Интернете. Например, 300 (множественный выбор) будет полезен для выполнения некоторых маркетинговых стратегий, когда пользователь должен выбирать между несколькими объектами одновременно. Код состояния 303 (см. Прочее) пригодится, когда другой URL-адрес должен использоваться для перенаправления на интересующий ресурс.

Но основные коды HTTP 300 — это 301, 302 и 307, потому что они используются для временных и постоянных перенаправлений. Эти коды состояния рекомендуются для обеспечения миграции веб-сайтов с оптимизацией поисковых систем, изменения URL-адресов, реструктуризации и обновлений сайта, смены доменов или коротких повторных публикаций для страниц веб-сайтов.

Стоит отметить, что к процессу перенаправления предъявляются некоторые требования, чтобы соответствовать стандартам рейтинга Google и не терять ссылочный вес. Следует помнить пять основных советов:

• Переходите на новый домен только после 301 редиректа. Google не любит дублированный контент и может наказать вас за эту ошибку.
• Установите 301, 302 и 307 редирект между версиями http://и http://wwwвашего домена. Это очень важно для вашей поисковой оптимизации.
• Обратите внимание на предпочтения Google в отношении цепочек переадресации. Не превышайте двух переадресаций подряд. В случае чрезмерного использования переадресации сканеры перестанут посещать ваш сайт.
• Используйте полезные инструменты, такие как Google Search Console, HTTP Status, WTOOLS HTTP Checker, Redirect Checker или инструмент аудита веб-сайтов для ранжирования SE, чтобы упростить мониторинг кода состояния HTTP и своевременное внесение изменений.
• Перепланируйте свою стратегию SEO, если вы собираетесь перейти с одного веб-сайта на другой. Рассмотрите поиск по ключевым словам, новые стратегии контент-маркетинга и другие фундаментальные приготовления.

From Wikipedia, the free encyclopedia

This is a list of Hypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The optional message phrases shown are typical, but any human-readable alternative may be provided, or none at all.

Unless otherwise stated, the status code is part of the HTTP standard (RFC 9110).

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.^[1]

All HTTP response status codes are separated into five classes or categories. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. There are five classes defined by the standard:

• 1xx informational response – the request was received, continuing process
• 2xx successful – the request was successfully received, understood, and accepted
• 3xx redirection – further action needs to be taken in order to complete the request
• 4xx client error – the request contains bad syntax or cannot be fulfilled
• 5xx server error – the server failed to fulfil an apparently valid request

1xx informational response

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not^{[note 1]} send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.

100 Continue

The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request’s headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).^[2]

101 Switching Protocols

The requester has asked the server to switch protocols and the server has agreed to do so.

102 Processing (WebDAV; RFC 2518)

A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.^[3] This prevents the client from timing out and assuming the request was lost. The status code is deprecated.^[4]

103 Early Hints (RFC 8297)

Used to return some response headers before final HTTP message.^[5]

2xx success

This class of status codes indicates the action requested by the client was received, understood, and accepted.^[1]

200 OK

Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.

201 Created

The request has been fulfilled, resulting in the creation of a new resource.^[6]

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.

203 Non-Authoritative Information (since HTTP/1.1)

The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.^[7][8]

204 No Content

The server successfully processed the request, and is not returning any content.

205 Reset Content

The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.

206 Partial Content

The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

207 Multi-Status (WebDAV; RFC 4918)

The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.^[9]

208 Already Reported (WebDAV; RFC 5842)

The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.

226 IM Used (RFC 3229)

The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.^[10]

3xx redirection

This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.^[1]

A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. A user agent should detect and intervene to prevent cyclical redirects.^[11]

300 Multiple Choices

Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.

301 Moved Permanently

This and all future requests should be directed to the given URI.

302 Found (Previously «Moved temporarily»)

Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),^[12] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.^[11]

303 See Other (since HTTP/1.1)

The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.

304 Not Modified

Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.

305 Use Proxy (since HTTP/1.1)

The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.

306 Switch Proxy

No longer used. Originally meant «Subsequent requests should use the specified proxy.»

307 Temporary Redirect (since HTTP/1.1)

In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.

308 Permanent Redirect

This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

This class of status code is intended for situations in which the error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.

400 Bad Request

The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).

401 Unauthorized

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.

Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.^{[citation needed]}

402 Payment Required

Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,^[14] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.^[15] Sipgate uses this code if an account does not have sufficient funds to start a call.^[16] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[17] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[18]

403 Forbidden

The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.

404 Not Found

The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.

405 Method Not Allowed

A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.

406 Not Acceptable

The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.

407 Proxy Authentication Required

The client must first authenticate itself with the proxy.

408 Request Timeout

The server timed out waiting for the request. According to HTTP specifications: «The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.»

409 Conflict

Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.

410 Gone

Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.

411 Length Required

The request did not specify the length of its content, which is required by the requested resource.

412 Precondition Failed

The server does not meet one of the preconditions that the requester put on the request header fields.

413 Payload Too Large

The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.^[19]

414 URI Too Long

The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.^[20]

415 Unsupported Media Type

The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

416 Range Not Satisfiable

The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.^[21]

417 Expectation Failed

The server cannot meet the requirements of the Expect request-header field.^[22]

418 I’m a teapot (RFC 2324, RFC 7168)

This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.^[23] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[24][25][26] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[27][28]

421 Misdirected Request

The request was directed at a server that is not able to produce a response (for example because of connection reuse).

422 Unprocessable Entity

The request was well-formed but was unable to be followed due to semantic errors.^[9]

423 Locked (WebDAV; RFC 4918)

The resource that is being accessed is locked.^[9]

424 Failed Dependency (WebDAV; RFC 4918)

The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).^[9]

425 Too Early (RFC 8470)

Indicates that the server is unwilling to risk processing a request that might be replayed.

426 Upgrade Required

The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.

428 Precondition Required (RFC 6585)

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.^[29]

429 Too Many Requests (RFC 6585)

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

431 Request Header Fields Too Large (RFC 6585)

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

451 Unavailable For Legal Reasons (RFC 7725)

A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.^[30] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

Response status codes beginning with the digit «5» indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error

A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

501 Not Implemented

The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).

502 Bad Gateway

The server was acting as a gateway or proxy and received an invalid response from the upstream server.

503 Service Unavailable

The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.^[31]

504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.

505 HTTP Version Not Supported

The server does not support the HTTP version used in the request.

506 Variant Also Negotiates (RFC 2295)

Transparent content negotiation for the request results in a circular reference.^[32]

507 Insufficient Storage (WebDAV; RFC 4918)

The server is unable to store the representation needed to complete the request.^[9]

508 Loop Detected (WebDAV; RFC 5842)

The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).

510 Not Extended (RFC 2774)

Further extensions to the request are required for the server to fulfil it.^[33]

511 Network Authentication Required (RFC 6585)

The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).^[29]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework)

Used by the Laravel Framework when a CSRF Token is missing or expired.

420 Method Failure (Spring Framework)

A deprecated response used by the Spring Framework when a method has failed.^[34]

420 Enhance Your Calm (Twitter)

Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.^[35] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.^{[citation needed]}

430 Request Header Fields Too Large (Shopify)

Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.^[36]

450 Blocked by Windows Parental Controls (Microsoft)

The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.^[37]

498 Invalid Token (Esri)

Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.^[38]

499 Token Required (Esri)

Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.^[38]

509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)

The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.^[39]

529 Site is overloaded

Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.^[40]

530 Site is frozen

Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.^[41]

598 (Informal convention) Network read timeout error

Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.^[42]

599 Network Connect Timeout Error

An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

Microsoft’s Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client’s request.

440 Login Time-out

The client’s session has expired and must log in again.^[43]

449 Retry With

The server cannot honour the request because the user has not provided the required information.^[44]

451 Redirect

Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.^[45] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.^[46]

IIS sometimes uses additional decimal sub-codes for more specific information,^[47] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.

nginx

The nginx web server software expands the 4xx error space to signal issues with the client’s request.^[48][49]

444 No Response

Used internally^[50] to instruct the server to return no information to the client and close the connection immediately.

494 Request header too large

Client sent too large request or too long header line.

495 SSL Certificate Error

An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.

496 SSL Certificate Required

An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.

497 HTTP Request Sent to HTTPS Port

An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.

499 Client Closed Request

Used when the client has closed the request before the server could send a response.

Cloudflare

Cloudflare’s reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.^[51]

520 Web Server Returned an Unknown Error

The origin server returned an empty, unknown, or unexpected response to Cloudflare.^[52]

521 Web Server Is Down

The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.

522 Connection Timed Out

Cloudflare timed out contacting the origin server.

523 Origin Is Unreachable

Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.

524 A Timeout Occurred

Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.

525 SSL Handshake Failed

Cloudflare could not negotiate a SSL/TLS handshake with the origin server.

526 Invalid SSL Certificate

Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.

527 Railgun Error

Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.^[53]

530

Error 530 is returned along with a 1xxx error.^[54]

AWS Elastic Load Balancer

Amazon’s Elastic Load Balancing adds a few custom return codes

460

Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.^[55]

463

The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.^[55]

464

Incompatible protocol versions between Client and Origin server.^[55]

561 Unauthorized

An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.^[55]

Caching warning codes (obsoleted)

The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the «Warning» HTTP header.^[56][57]

Since this «Warning» header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111.^[58]

110 Response is Stale

The response provided by a cache is stale (the content’s age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).

111 Revalidation Failed

The cache was unable to validate the response, due to an inability to reach the origin server.

112 Disconnected Operation

The cache is intentionally disconnected from the rest of the network.

113 Heuristic Expiration

The cache heuristically chose a freshness lifetime greater than 24 hours and the response’s age is greater than 24 hours.

199 Miscellaneous Warning

Arbitrary, non-specific warning. The warning text may be logged or presented to the user.

214 Transformation Applied

Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.

299 Miscellaneous Persistent Warning

Same as 199, but indicating a persistent warning.

See also

• Custom error pages
• List of FTP server return codes
• List of HTTP header fields
• List of SMTP server return codes
• Common Log Format

Explanatory notes

References

External links

• «RFC 9110: HTTP Semantics and Content, Section 15 «Status Codes»«.
• Hypertext Transfer Protocol (HTTP) Status Code Registry at the Internet Assigned Numbers Authority
• MDN status code reference at mozilla.org

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

Класс кода состояния 3xx (перенаправление) указывает, что пользовательский агент должен предпринять дальнейшие действия для выполнения запроса. Существует несколько типов перенаправлений: 1. Перенаправления, которые указывают, что этот ресурс может быть доступен по другому URI, указанному в поле заголовка Location, как в кодах состояния 301 (перемещено навсегда), 302 (найдено), 307 (временное перенаправление). ) и 308 (постоянная переадресация). 2. Перенаправление, которое предлагает выбор среди соответствующих ресурсов, способных представлять этот ресурс, как в коде состояния 300 (множественный выбор). 3. Перенаправление на другой ресурс, указанный в поле заголовка Location, который может представлять косвенный ответ на запрос, как в коде состояния 303 (см. Другое). 4. Перенаправление на ранее сохраненный результат, как в коде состояния 304 (не изменено). | *Примечание:* В HTTP/1.0, коды состояния 301 (перемещено навсегда) | и 302 (Найдено) изначально были определены как сохраняющие метод | ([HTTP/1.0],Раздел 9.3 ), чтобы соответствовать их реализации на | ЦЕРН; 303 (см. Другое) был определен для перенаправления, которое | изменил свой метод на GET. Однако ранние пользовательские агенты разделились на | следует ли перенаправлять POST-запросы как POST (в соответствии с текущей спецификацией) или как GET (более безопасная альтернатива при перенаправлении на другой сайт). Преобладающая практика | в итоге сошлись на изменении метода на GET. 307 | (временное перенаправление) и 308 (постоянное перенаправление) [ RFC7538 ] | позже были добавлены, чтобы недвусмысленно указать на сохранение метода | перенаправления, а коды состояния 301 и 302 изменены на | разрешить перенаправление запроса POST как GET. Если поле заголовка Location ( Раздел 10.2.2), пользовательский агент МОЖЕТ автоматически перенаправить свой запрос на URI, на который ссылается значение поля Location, даже если конкретный код состояния не понят. Автоматическое перенаправление необходимо выполнять с осторожностью для методов, безопасность которых не известна, как определено в Разделе 9.2.1., так как пользователь может не захотеть перенаправлять небезопасный запрос. При автоматическом выполнении перенаправленного запроса пользовательский агент ДОЛЖЕН повторно отправить исходное сообщение запроса со следующими изменениями: 1. Заменить целевой URI на URI, на который ссылается значение поля заголовка Location ответа о перенаправлении, после разрешения его относительно целевого URI исходного запроса. 2. Удалите поля заголовков, автоматически сгенерированные реализацией, заменив их обновленными значениями в соответствии с новым запросом. Сюда входят: 1. Поля заголовка, относящиеся к соединению (см. раздел 7.6.1) .), 2. Поля заголовков, относящиеся к конфигурации прокси-сервера клиента, включая (но не ограничиваясь) прокси-авторизацию, 3. Поля заголовка, относящиеся к происхождению (если есть), включая (но не ограничиваясь) Хост, 4. Проверка полей заголовка которые были добавлены кешем реализации (например, If-None-Match, If-Modified-Since) и 5. Поля заголовка для конкретного ресурса, включая (но не ограничиваясь) Referer, Origin, Authorization и Cookie. 3. Рассмотрите возможность удаления полей заголовков, которые не были автоматически сгенерированы реализацией (т. е. те, которые присутствуют в запросе, потому что они были добавлены вызывающим контекстом), если это влияет на безопасность; это включает, но не ограничивается авторизацией и файлами cookie. 4. Измените метод запроса в соответствии с семантикой кода состояния перенаправления, если применимо. 5. Если метод запроса был изменен на GET или HEAD, удалите поля заголовка, относящиеся к содержимому, включая (но не ограничиваясь) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, Last- Изменено. Клиенту СЛЕДУЕТ обнаруживать и вмешиваться в циклические перенаправления (т. е. «бесконечные» циклы перенаправления). | *Примечание:* В более ранней версии этой спецификации рекомендовалось | максимум пять перенаправлений ([RFC2068], раздел 10.3 ). | Разработчики контента должны знать, что некоторые клиенты могут | реализовать такое фиксированное ограничение.

15.4.1.300 Множественный выбор

Код состояния 300 (Multiple Choices) указывает, что целевой ресурс имеет более одного представления, каждое со своим собственным более конкретным идентификатором, и предоставляется информация об альтернативах, чтобы пользователь (или пользовательский агент) мог выбрать предпочтительное представление путем перенаправляя свой запрос на один или несколько из этих идентификаторов. Другими словами, сервер хочет, чтобы пользовательский агент участвовал в реактивном согласовании, чтобы выбрать наиболее подходящее представление (представления) для его нужд ( раздел 12 ).). Если у сервера есть предпочтительный выбор, сервер ДОЛЖЕН создать поле заголовка Location, содержащее ссылку URI предпочтительного выбора. Пользовательский агент МОЖЕТ использовать значение поля Location для автоматического перенаправления. Для методов запроса, отличных от HEAD, серверу СЛЕДУЕТ генерировать контент в ответе 300, содержащем список метаданных представления и ссылки(и) URI, из которых пользователь или пользовательский агент может выбрать наиболее предпочтительный. Пользовательский агент МОЖЕТ сделать выбор из этого списка автоматически, если он понимает предоставленный тип носителя. Конкретный формат для автоматического выбора не определяется этой спецификацией, поскольку HTTP пытается оставаться ортогональным определению своего содержимого. На практике представление предоставляется в некотором легко анализируемом формате, который считается приемлемым для пользовательского агента. как определено общим дизайном или согласованием содержания, или в каком-либо общепринятом гипертекстовом формате. Ответ 300 эвристически кэшируется; т.е., если иное не указано в определении метода или явных элементах управления кешем (см. Раздел 4.2.2 в [КЭШИРОВАНИЕ ]). | *Примечание:* Исходное предложение для кода состояния 300 определено | поле заголовка URI как предоставляющее список альтернативных | представления, чтобы его можно было использовать для 200, 300 и | 406 ответов и передаваться в ответах на HEAD | метод. Тем не менее, отсутствие развертывания и разногласия по | синтаксис привел как к URI, так и к альтернативам (последующее предложение) | исключаются из этой спецификации. Можно | передать список как значение поля заголовка Link [ RFC8288 ] | чьи члены имеют отношения «альтернативные», хотя | развертывание — это проблема курицы и яйца.

15.4.2. 301 Moved Permanently

Код состояния 301 (перемещен навсегда) указывает, что целевому ресурсу был назначен новый постоянный URI, и любые будущие ссылки на этот ресурс должны использовать один из заключенных URI. Сервер предполагает, что пользовательский агент с возможностью редактирования ссылок может навсегда заменить ссылки на целевой URI одной из новых ссылок, отправленных сервером. Однако это предложение обычно игнорируется, за исключением случаев, когда пользовательский агент активно редактирует ссылки (например, занимается созданием контента), соединение защищено, а исходный сервер является доверенным лицом для редактируемого контента. Серверу СЛЕДУЕТ генерировать поле заголовка Location в ответе, содержащем предпочтительную ссылку URI для нового постоянного URI. Пользовательский агент МОЖЕТ использовать значение поля Location для автоматического перенаправления. Сервер’ Содержимое ответа обычно содержит короткую гипертекстовую заметку с гиперссылкой на новые URI. | *Примечание:* По историческим причинам пользовательский агент МОЖЕТ изменить | метод запроса от POST к GET для последующего запроса. Если | такое поведение нежелательно, статус 308 (постоянная переадресация) | вместо него можно использовать код. Ответ 301 эвристически кэшируется; т.е., если иное не указано в определении метода или явных элементах управления кешем (см. Раздел 4.2.2 в [КЭШИРОВАНИЕ ]).

15.4.3.302 Найдено

Код состояния 302 (Found)указывает на то,что целевой ресурс временно находится под другим URI.Поскольку перенаправление может быть изменено,клиент должен продолжать использовать целевой URI для будущих запросов.Сервер ДОЛЖЕН генерировать поле заголовка Location в ответе,содержащее ссылку URI для другого URI.Агент пользователя МОЖЕТ использовать значение поля Location для автоматического перенаправления.Содержимое ответа сервера обычно содержит короткую гипертекстовую заметку с гиперссылкой на различные URI.| *Примечание:*По историческим причинам агент пользователя может изменить метод запроса с POST на GET для последующего запроса.Если такое поведение нежелательно,| вместо него может быть использован код состояния 307 (Temporary Redirect)|.

15.4.4.303 См.другое

Код состояния 303 (See Other)указывает на то,что сервер перенаправляет агента пользователя на другой ресурс,указанный URI в поле заголовка Location,который предназначен для предоставления косвенного ответа на исходный запрос.Агент пользователя может выполнить запрос на поиск,направленный на этот URI (запрос GET или HEAD,если используется HTTP),который также может быть перенаправлен,и представить конечный результат в качестве ответа на исходный запрос.Обратите внимание,что новый URI в поле заголовка Location не считается эквивалентным целевому URI.Этот код состояния применим к любому методу HTTP.В первую очередь он используется для того,чтобы позволить результату действия POST перенаправить агента пользователя на другой ресурс,поскольку при этом информация,соответствующая ответу POST,представляется как ресурс,который можно отдельно идентифицировать,добавить в закладки и кэшировать.Ответ 303 на запрос GET указывает на то,что сервер происхождения не имеет представления целевого ресурса,которое может быть передано сервером по HTTP.Однако значение поля Location ссылается на ресурс,который является описанием целевого ресурса,так что запрос на поиск на этом другом ресурсе может привести к представлению,полезному для получателей,не подразумевая,что оно представляет исходный целевой ресурс.Обратите внимание,что ответы на вопросы о том,что может быть представлено,какие представления являются адекватными,и что может быть полезным описанием,выходят за рамки HTTP.За исключением ответов на запрос HEAD,представление ответа 303 должно содержать короткую гипертекстовую заметку с гиперссылкой на ту же самую ссылку URI,указанную в поле заголовка Location.

15.4.5.304 Не изменено

Код состояния 304 (не изменен) указывает на то, что условный запрос GET или HEAD был получен и привел бы к ответу 200 (ОК), если бы не тот факт, что условие оценено как ложное. Другими словами, серверу нет необходимости передавать представление целевого ресурса, поскольку запрос указывает, что клиент, сделавший запрос условным, уже имеет допустимое представление; поэтому сервер перенаправляет клиента на использование этого сохраненного представления, как если бы оно было содержимым ответа 200 (ОК). Сервер, генерирующий ответ 304, ДОЛЖЕН генерировать любое из следующих полей заголовка, которые были бы отправлены в ответе 200 (ОК) на тот же запрос: * Content-Location, Date, ETag и Vary * Cache-Control и Expires (см. [ КЭШИРОВАНИЕ]) Поскольку целью ответа 304 является минимизация передачи информации, когда у получателя уже есть одно или несколько кэшированных представлений, отправителю НЕ СЛЕДУЕТ генерировать метаданные представления, отличные от перечисленных выше полей, если только указанные метаданные не существуют для целей управления обновлениями кэша ( например, Last-Modified может быть полезен, если в ответе нет поля ETag). Требования к кэшу, который получает ответ 304, определены в Разделе 4.3.4 [ КЭШИРОВАНИЕ ]. Если условный запрос исходит от исходящего клиента, такого как пользовательский агент с собственным кешем, отправляющий условный GET на общий прокси-сервер, то прокси-сервер ДОЛЖЕН перенаправить ответ 304 этому клиенту. Ответ 304 завершается в конце раздела заголовка; он не может содержать контент или трейлеры.

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

Код состояния 305 (Использование прокси-сервера) был определен в предыдущей версии этой спецификации и теперь устарел (Приложение B к [ RFC7231 ]).

15.4.7.306 (Не используется)

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

15.4.8.307 Временное перенаправление

Код состояния 307 (Temporary Redirect)указывает на то,что целевой ресурс временно находится под другим URI и агент пользователя НЕ ДОЛЖЕН менять метод запроса,если он выполняет автоматическое перенаправление на этот URI.Поскольку перенаправление может измениться со временем,клиент должен продолжать использовать исходный целевой URI для будущих запросов.Сервер ДОЛЖЕН генерировать поле заголовка Location в ответе,содержащее ссылку URI для другого URI.Агент пользователя МОЖЕТ использовать значение поля Location для автоматического перенаправления.Содержимое ответа сервера обычно содержит короткую гипертекстовую заметку с гиперссылкой на другой URI (ы).

15.4.9.308 Постоянное перенаправление

Код состояния 308 (постоянное перенаправление) указывает, что целевому ресурсу был назначен новый постоянный URI, и любые будущие ссылки на этот ресурс должны использовать один из заключенных URI. Сервер предполагает, что пользовательский агент с возможностью редактирования ссылок может навсегда заменить ссылки на целевой URI одной из новых ссылок, отправленных сервером. Однако это предложение обычно игнорируется, за исключением случаев, когда пользовательский агент активно редактирует ссылки (например, занимается созданием контента), соединение защищено, а исходный сервер является доверенным лицом для редактируемого контента. Серверу СЛЕДУЕТ генерировать поле заголовка Location в ответе, содержащем предпочтительную ссылку URI для нового постоянного URI. Пользовательский агент МОЖЕТ использовать значение поля Location для автоматического перенаправления. Сервер’ Содержимое ответа обычно содержит короткую гипертекстовую заметку с гиперссылкой на новые URI. Ответ 308 эвристически кэшируется; т.е., если иное не указано в определении метода или явных элементах управления кешем (см. Раздел 4.2.2 в [КЭШИРОВАНИЕ ]). | *Примечание:* Этот код состояния намного моложе (июнь 2014 г.), чем его | родственные коды и, таким образом, не везде могут быть распознаны. См. | Раздел 4 [RFC7538] для соображений развертывания.

HTTP

• 14.2. Range

  14.2.

• 14.6.Тип носителя multipart/byteranges

  14.6.

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

  15.5.

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

  15.6.