From Wikipedia, the free encyclopedia
HTTP 301 is the HTTP response status code for 301 Moved Permanently. It is used for permanent redirecting, meaning that links or records returning this response should be updated. The new URL should be provided in the Location field, included with the response. The 301 redirect is considered a best practice for upgrading users from HTTP to HTTPS.
RFC 2616[1] states that:
- If a client has link-editing capabilities, it should update all references to the Request URL.
- The response is cacheable unless indicated otherwise.
- Unless the request method was HEAD, the entity should contain a small hypertext note with a hyperlink to the new URL(s).
- If the 301 status code is received in response to a request of any type other than GET or HEAD, the client must ask the user before redirecting.
Examples[edit]
Client request:
GET /index.php HTTP/1.1 Host: www.example.org
Server response:
HTTP/1.1 301 Moved Permanently Location: https://www.example.org/index.asp
Using an .htaccess file[edit]
To fix problems with non-existing files or directories using a distributed .htaccess file:
Redirect 301 /calendar.html /calendar/ Redirect 301 /not_found.html /
Here is an example using a .htaccess file to redirect a non-secure URL to a secure address without the leading «www»:
RewriteEngine On RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L] RewriteCond %{HTTPS} on RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC] RewriteRule ^(.*)$ https://%1/$1 [R=301,L] RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://example.com/$1 [R,L]
100% Completed
Static HTML[edit]
A custom directory redirect, using an index.html file:
<meta http-equiv="refresh" content="0; url=/" /> <p><a href="/">Home</a></p>
Using programming languages[edit]
Here is an example using Perl CGI.pm:
print redirect("https://example.com/newpage.html");
Here is an example using a PHP redirect:
<?php header("Location: https://example.com/newpage.html", true, 301); exit;
Here is one way to redirect using Express.js:
app.all("/old/url", (req, res) => { res.redirect(301, "/new/url"); });
Caching server[edit]
Equivalently simple for an nginx configuration:
location /old/urlblocked/ { return 301 /new/url/stay standard structure }
On
Search engines[edit]
Both Bing and Google recommend using a 301 redirect to change the URL of a page as it is shown in search engine results, providing that URL will permanently change and is not due to be changed again any time soon.[2][3]
See also[edit]
- Hypertext Transfer Protocol
- List of HTTP status codes
- URL redirection
References[edit]
- ^ Fielding; et al. (June 1999). 10.3.2 301 Moved Permanently. IETF. p. 61. sec. 10.3.2. doi:10.17487/RFC2616. RFC 2616.
- ^ «Site Move Tool». Bing Webmaster Help & How-to.
- ^ «301 redirects». Google Webmaster Tools Help.
REST API использует строку состояния в HTTP ответе (статус ответа), чтобы информировать Клиентов о результате запроса.
Вообще HTTP определяет 40 стандартных кодов состояния (статусов ответа), которые делятся на пять категорий. Ниже выделены только те коды состояния, которые часто используются в REST API.
| Категория | Описание |
|---|---|
| 1xx: Информация | В этот класс содержит заголовки информирующие о процессе передачи. Это обычно предварительный ответ, состоящий только из Status-Line и опциональных заголовков, и завершается пустой строкой. Нет обязательных заголовков. Серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам. |
| 2xx: Успех | Этот класс кодов состояния указывает, что запрос клиента был успешно получен, понят, и принят. |
| 3xx: Перенаправление | Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. |
| 4xx: Ошибка клиента | Класс кодов 4xx предназначен для указания ошибок со стороны клиента. |
| 5xx: Ошибка сервера | Коды ответов, начинающиеся с «5» указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос. |
Коды состояний в REST
Звездочкой * помечены популярные (часто используемые) коды ответов.
200 * (OK)
Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например при:
- GET Получен объект, соответствующий запрошенному ресурсу.
- HEAD Получены поля заголовков, соответствующие запрошенному ресурсу, тело ответа пустое.
- POST Запрошенное действие выполнено.
201 * (Created — Создано)
REST API отвечает кодом состояния 201 при каждом создании ресурса в коллекции. Также могут быть случаи, когда новый ресурс создается в результате какого-либо действия контроллера, и в этом случае 201 также будет подходящем ответом.
Ссылка (URL) на новый ресурс может быть в теле ответа или в поле заголовка ответа Location.
Сервер должен создать ресурс перед тем как вернуть 201 статус. Если это невозможно сделать сразу, тогда сервер должен ответить кодом 202 (Accepted).
202 (Accepted — Принято)
Ответ 202 обычно используется для действий, которые занимают много времени для обработки и не могут быть выполнены сразу. Это означает, что запрос принят к обработке, но обработка не завершена.
Его цель состоит в том, чтобы позволить серверу принять запрос на какой-либо другой процесс (возможно, пакетный процесс, который выполняется только один раз в день), не требуя, чтобы соединение агента пользователя с сервером сохранялось до тех пор, пока процесс не будет завершен.
Сущность, возвращаемая с этим ответом, должна содержать указание на текущее состояние запроса и указатель на монитор состояния (расположение очереди заданий) или некоторую оценку того, когда пользователь может ожидать выполнения запроса.
203 (Non-Authoritative Information — Неавторитетная информация)
Предоставленная информация взята не из оригинального источника (а, например, из кэша, который мог устареть, или из резервной копии, которая могла потерять актуальность). Этот факт отражен в заголовке ответа и подтверждается этим кодом. Предоставленная информация может совпадать, а может и не совпадать с оригинальными данными.
204 * (No Content — Нет контента)
Код состояния 204 обычно отправляется в ответ на запрос PUT, POST или DELETE, когда REST API отказывается отправлять обратно любое сообщение о состоянии проделанной работы.
API может также отправить 204 статус в ответ на GET запрос, чтобы указать, что запрошенный ресурс существует, но не имеет данных для добавления их в тело ответа.
Ответ 204 не должен содержать тело сообщения и, таким образом, всегда завершается первой пустой строкой после полей заголовка.
205 — (Reset Content — Сброшенное содержимое)
Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяется для возврата в начальное состояние формы ввода данных на клиенте.
206 — (Partial Content — Частичное содержимое)
Сервер выполнил часть 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).
300 — (Multiple Choices — Несколько вариантов)
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю.
Если это не запрос HEAD, ответ ДОЛЖЕН включать объект, содержащий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется по типу данных приведённых в Content-Type поля заголовка. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако эта спецификация не определяет никакого стандарта для автоматического выбора.
Если у сервера есть предпочтительный выбор представления, он ДОЛЖЕН включить конкретный URI для этого представления в поле Location; агент пользователя МОЖЕТ использовать заголовок Location для автоматического перенаправления к предложенному ресурсу. Этот запрос может быть закэширован, если явно не было указано иного.
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 (See Other — Смотрите другое)
Ответ 303 указывает, что ресурс контроллера завершил свою работу, но вместо отправки нежелательного тела ответа он отправляет клиенту URI ресурса. Это может быть URI временного сообщения о состоянии ресурса или URI для уже существующего постоянного ресурса.
Код состояния 303 позволяет REST API указать ссылку на ресурс, не заставляя клиента загружать ответ. Вместо этого клиент может отправить GET запрос на URL указанный в заголовке Location.
Ответ 303 не должен кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэшируемым.
304 * (Not Modified — Не изменен)
Этот код состояния похож на 204 (Нет контента), так как тело ответа должно быть пустым. Ключевое различие состоит в том, что 204 используется, когда нет ничего для отправки в теле, тогда как 304 используется, когда ресурс не был изменен с версии, указанной заголовками запроса If-Modified-Since или If-None-Match.
В таком случае нет необходимости повторно передавать ресурс, так как у клиента все еще есть ранее загруженная копия.
Все это экономит ресурсы клиента и сервера, так как только заголовки должны быть отправлены и приняты, и серверу нет необходимости генерировать контент снова, а клиенту его получать.
305 — (Use Proxy — Используйте прокси)
Доступ к запрошенному ресурсу ДОЛЖЕН быть осуществлен через прокси-сервер, указанный в поле Location. Поле Location предоставляет URI прокси. Ожидается, что получатель повторит этот запрос с помощью прокси. Ответ 305 может генерироваться ТОЛЬКО серверами-источниками.
Заметьте: в спецификации RFC 2068 однозначно не сказано, что ответ 305 предназначен для перенаправления единственного запроса, и что он должен генерироваться только сервером-источником. Упущение этих ограничений вызвало ряд значительных последствий для безопасности.
Многие HTTP клиенты (такие, как Mozilla и Internet Explorer) обрабатывают этот статус некорректно прежде всего из соображений безопасности.
307 (Temporary Redirect — Временный редирект)
Ответ 307 указывает, что rest API не будет обрабатывать запрос клиента. Вместо этого клиент должен повторно отправить запрос на URL, указанный в заголовке Location. Однако в будущих запросах клиент по-прежнему должен использоваться исходный URL.
Rest API может использовать этот код состояния для назначения временного URL запрашиваемому ресурсу.
Если метод запроса не HEAD, тело ответа должно содержать короткую заметку с гиперссылкой на новый URL. Если код 307 был получен в ответ на запрос, отличный от GET или HEAD, Клиент не должен автоматически перенаправлять запрос, если он не может быть подтвержден Клиентом, так как это может изменить условия, при которых был создан запрос.
308 — (Permanent Redirect — Постоянное перенаправление) (experimental)
Нужно повторить запрос на другой адрес без изменения применяемого метода.
Этот и все последующие запросы нужно повторить на другой URI. 307 и 308 (как предложено) Схож в поведении с 302 и 301, но не требуют замены HTTP метода. Таким образом, например, отправку формы на «постоянно перенаправленный» ресурс можно продолжать без проблем.
400 * (Bad Request — Плохой запрос)
Это общий статус ошибки на стороне Клиента. Используется, когда никакой другой код ошибки 4xx не уместен. Ошибки могут быть как неправильный синтаксис запроса, неверные параметры запроса, запросы вводящие в заблуждение или маршрутизатор и т.д.
Клиент не должен повторять точно такой же запрос.
401 * (Unauthorized — Неавторизован)
401 сообщение об ошибке указывает, что клиент пытается работать с закрытым ресурсом без предоставления данных авторизации. Возможно, он предоставил неправильные учетные данные или вообще ничего. Ответ должен включать поле заголовка WWW-Authenticate, содержащего описание проблемы.
Клиент может повторить запрос указав в заголовке подходящее поле авторизации. Если это уже было сделано, то в ответе 401 будет указано, что авторизация для указанных учетных данных не работает. Если в ответе 401 содержится та же проблема, что и в предыдущем ответе, и Клиент уже предпринял хотя бы одну попытку проверки подлинности, то пользователю Клиента следует представить данные полученные в ответе, владельцу сайта, так как они могут помочь в диагностике проблемы.
402 — (Payment Required — Требуется оплата)
Этот код зарезервирован для использования в будущем.
Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.
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.
В таких случаях Клиент должен решить проблему данных у себя и только потом отправлять запросы повторно.
407 — (Proxy Authentication Required — Требуется прокси-аутентификация)
Ответ аналогичен коду 401, за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.
Пользователь должен сначала авторизоваться через прокси. Прокси-сервер должен вернуть Proxy-Authenticate заголовок, содержащий запрос ресурса. Клиент может повторить запрос вместе с Proxy-Authenticate заголовком. Появился в HTTP/1.1.
408 — (Request Timeout — Таймаут запроса)
Время ожидания сервером передачи от клиента истекло. Клиент не предоставил запрос за то время, пока сервер был готов его принят. Клиент МОЖЕТ повторить запрос без изменений в любое время.
Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос.
409 * (Conflict — Конфликт)
Запрос нельзя обработать из-за конфликта в текущем состоянии ресурса. Этот код разрешается использовать только в тех случаях, когда ожидается, что пользователь может самостоятельно разрешить этот конфликт и повторить запрос. В тело ответа СЛЕДУЕТ включить достаточное количество информации для того, чтобы пользователь смог понять причину конфликта. В идеале ответ должен содержать такую информацию, которая поможет пользователю или его агенту исправить проблему. Однако это не всегда возможно и это не обязательно.
Как правило, конфликты происходят во время PUT-запроса. Например, во время использования версионирования, если сущность, к которой обращаются методом PUT, содержит изменения, конфликтующие с теми, что были сделаны ранее третьей стороной, серверу следует использовать ответ 409, чтобы дать понять пользователю, что этот запрос нельзя завершить. В этом случае в ответной сущности должен содержаться список изменений между двумя версиями в формате, который указан в поле заголовка Content-Type.
410 — (Gone — Исчез)
Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.
411 — (Length Required — Требуется длина)
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение.
412 — (Precondition Failed — Предварительное условие не выполнено)
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.
Когда клиент указывает rest API выполнять запрос только при выполнении определенных условий, а API не может выполнить запрос при таких условиях, то возвращается ответ 412.
Этот код ответа позволяет клиенту записывать предварительные условия в метаинформации текущего ресурса, таким образом, предотвращая применение запрошенного метода к ресурсу, кроме того, что ожидается.
413 — (Request Entity Too Large — Сущность запроса слишком большая)
Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса.
Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.
414 — (Request-URI Too Long — Запрос-URI Слишком длинный)
Сервер не может обработать запрос из-за слишком длинного указанного URL. Эту редкую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST, когда клиент попадает в «чёрную дыру» перенаправлений (например, когда префикс URI указывает на своё же окончание), или когда сервер подвергается атаке со стороны клиента, который пытается использовать дыры в безопасности, которые встречаются на серверах с фиксированной длиной буфера для чтения или обработки Request-URI.
415 (Unsupported Media Type — Неподдерживаемый медиа тип)
Сообщение об ошибке 415 указывает, что API не может обработать предоставленный клиентом Тип медиа, как указано в заголовке запроса Content-Type.
Например, запрос клиента содержит данные в формате application/xml, а API готов обработать только application/json. В этом случае клиент получит ответ 415.
Например, клиент загружает изображение как image/svg+xml, но сервер требует, чтобы изображения использовали другой формат.
428 — (Precondition Required — Требуется предварительное условие)
Код состояния 428 указывает, что исходный сервер требует, чтобы запрос был условным.
Его типичное использование — избежать проблемы «потерянного обновления», когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и ОТПРАВЛЯЕТ обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту. Требуя, чтобы запросы были условными, сервер может гарантировать, что клиенты работают с правильными копиями.
Ответы с этим кодом состояния ДОЛЖНЫ объяснять, как повторно отправить запрос.
429 — (Too Many Requests — Слишком много запросов)
Пользователь отправил слишком много запросов за заданный промежуток времени.
Представления ответа ДОЛЖНЫ включать подробности, объясняющие условие, и МОГУТ включать заголовок Retry-After, указывающий, как долго ждать, прежде чем делать новый запрос.
431 — (Request Header Fields Too Large — Слишком большие поля заголовка запроса)
Код состояния 431 указывает на то, что сервер не желает обрабатывать запрос, поскольку его поля заголовка слишком велики. Запрос МОЖЕТ быть отправлен повторно после уменьшения размера полей заголовка запроса.
Его можно использовать как в случае, когда совокупность полей заголовка запроса слишком велика, так и в случае неисправности одного поля заголовка. В последнем случае представление ответа ДОЛЖНО указывать, какое поле заголовка было слишком большим.
444 — (No Response — Нет ответа) (Nginx)
Код ответа Nginx. Сервер не вернул информацию и закрыл соединение. (полезно в качестве сдерживающего фактора для вредоносных программ)
451 — (Unavailable For Legal Reasons — Недоступен по юридическим причинам)
Доступ к ресурсу закрыт по юридическим причинам. Наиболее близким из существующих является код 403 Forbidden (сервер понял запрос, но отказывается его обработать). Однако в случае цензуры, особенно когда это требование к провайдерам заблокировать доступ к сайту, сервер никак не мог понять запроса — он его даже не получил. Совершенно точно подходит другой код: 305 Use Proxy. Однако такое использование этого кода может не понравиться цензорам. Было предложено несколько вариантов для нового кода, включая «112 Emergency. Censorship in action» и «460 Blocked by Repressive Regime»
500 * (Internal Server Error — Внутренняя ошибка сервера)
Общий ответ при ошибке в коде. Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.
Большинство веб-платформ автоматически отвечают этим кодом состояния, когда при выполнении кода обработчика запроса возникла ошибка.
Ошибка 500 никогда не зависит от клиента, поэтому для клиента разумно повторить точно такой же запрос, и надеяться что в этот раз сервер отработает без ошибок.
501 (Not Implemented — Не реализован)
Серверу либо неизвестен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос. Обычно это подразумевает будущую доступность (например, новая функция API веб-сервиса).
Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405.
502 — (Bad Gateway — Плохой шлюз)
Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился. Появился в HTTP/1.0.
503 — (Service Unavailable — Служба недоступна)
Сервер не может обработать запрос из-за временной перегрузки или технических работ. Это временное состояние, из которого сервер выйдет через какое-то время. Если это время известно, то его МОЖНО передать в заголовке Retry-After.
504 — (Gateway Timeout — Таймаут шлюза)
Сервер, в роли шлюза или прокси-сервера, не дождался в рамках установленного таймаута ответа от вышестоящего сервера текущего запроса.
505 — (HTTP Version Not Supported — Версия HTTP не поддерживается)
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.
510 — (Not Extended — Не расширен)
В запросе не соблюдена политика доступа к ресурсу. Сервер должен отправить обратно всю информацию, необходимую клиенту для отправки расширенного запроса. Указание того, как расширения информируют клиента, выходит за рамки данной спецификации.
—
Источники и более подробная информация:
- https://restapitutorial.ru/httpstatuscodes.html
- https://www.restapitutorial.com/httpstatuscodes.html
- https://restfulapi.net/http-status-codes/
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428
HTTP Status 301 is one of the redirection related statuses, which indicates that the resource requested has been permanently moved to the URL given by the
Locationheader. And all the future requests should use the new URI.
Redirection is the process of forwarding the request from one URL to a different URL. The specification for Status 301 requires the request method (and the request body) not to be altered when the redirection is performed.
It is recommended to use HTTP 301 only for GET or HEAD methods.
1. Why a URL needs to move permanently?
Generally, changing the URLs of resources is not advisable. Still, we can come across unavoidable situations where we must be making the changes to the URL of a resource.
A few such examples can be:
- Moving the resource from HTTP to HTTPs protocol
- Resource has been discountinued and alternate resource is available in new URL
2. Location Header
The server SHOULD generate a Location header field in the response containing the new location of the resource.
2.1. Client request
GET /index.php HTTP/1.1
Host: www.example.com2.2. Server response
HTTP/1.1 301 Moved Permanently
Location: https://example.com/index.asp3. Cachable
A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls.
Refer to these cache headers for more information.
4. Response Handling
- If a client has link-editing capabilities, it should update all references to the requested URL with the new URL.
- Search engines (Google and Bing) replace the old URL in the search results, and the old URL will eventually disappear. Link juice will pass from the old URL to the new URL.
- The browsers will automatically detect the 301 response code after that it will read the new location URL and redirect the request to that new location.
Reference : RFC 7231
Introduction
Learn about 301 redirects and the most common errors so you can avoid them in
the future. Fortunately, you’ve found your way here.
Think of it as if you’re creating a brand new webpage or an entire website
from scratch. Alternatively, you may be moving your website. Your domain name
may contain a typo. You’ve concluded that using the same URL is no longer
feasible. What are you doing?
A 301 permanently relocated status code is what you use. The purpose of these
codes is to redirect your customers to a different location. «The requested
document has been permanently relocated.» Users will try to access a page, but
will instead be redirected elsewhere.
You need to know the
301 status code, as well as how to find and fix 301 errors, here.
What Does 301 Permanently Moved Mean?
HTTP status codes
come in a wide variety of flavors. There are a variety of ways to tell the
user if a specific HTTP request has been successful. In total, there are five
levels:
-
Responses that provide data (such as 100 Continue and 101 Switching
Protocols) - Successful outcomes
- Reroutes traffic
-
Mistakes by the user (like
404 Page Not Found) - as well as server issues
There is a redirection indicated by the 3xx HTTP status code. Instead of the
original URL, users and search engines will be redirected to a new one. There
are a variety of 3xx status codes, such as 302, 303, and 307, each with their
unique interpretation.
301 status codes should be used when you’re permanently changing one URL for
another. In other words, the old URL will be redirected to the new one for
people and bots alike.
Website.com/blog redirects to blog.website.com
It would sound something like this to a real person:
Visitor: For the time being, this page has been relocated, and we have
no plans to return it.
Browser: I see now. I’ll direct your existing customers to the new
URL.
There will be no need for the old URL, as it will no longer appear in the
search results. The old URL’s link equity will be transferred to the new
URL.
As a result, whenever you’re doing a site migration or removing an old page
and replacing it with a new one, you’ll want to perform a 301 Moved
Permanently redirect.
How do 301 and 302 redirections differ?
A 301 redirect is superior to a 302 redirect. Have trouble deciding which
one to use?
The fact that you’re feeling this way isn’t unique.
Even in 2019, website owners are unsure of which type of redirect is best for
search engine optimization (SEO).
A redirect can be useful for a variety of reasons. Below are the most
frequently used justifications:
- You’ve launched a brand-new site.
- Creation of a new page for you.
- There is a problem with your URL.
For example, you’re working on an issue with a page and want to redirect users
to another page.
The decision is heavily influenced by the redirect’s intended outcome. When it
comes to SEO, it’s important to know the difference between the two.
Search engines need to be informed that a website or page has been permanently
relocated by a 301 redirect. If you’re moving a website or creating a new one,
you should use an HTTP 301. Usage of 301 is appropriate if you’re joining two
websites together. However, 301 is also useful if you’re making modifications
to the URL that are not meant to be reversed.
Using a 302 redirect lets search engines know that a website or page has been
temporarily redirected elsewhere. If you’re redesigning or updating a website
or a page, you should use this redirect. You can also use the redirect to test
out a new page and get feedback from customers. Only use a 302 redirect if you
intend to bring the old website or page back online in the future.
A 301 redirect lasts how long?
It is typical for a 301 redirect to remain in place for a year or more. Check
to see if you’re new URL is still being sent to users after that.
Fixing 301 redirects is a question I frequently get
Error 301 is a common occurrence for website owners of all skill levels. To
keep your website in good working order, it’s important to know what’s wrong
and how to fix it. When dealing with these kinds of issues, regular website
maintenance is a must, and here are the most common and best ways to resolve
them.
Check to see if your HTTP version is redirecting to your HTTPS version.
Using HTTPS on your site can help protect the personal information of your
site’s visitors. For additional information, Google uses HTTPS as a ranking
factor. To put it another way, not encrypting your website traffic with HTTPS
can harm your search engine results. For the sake of everyone’s safety online,
Google hopes that this move will encourage all website owners to make the
switch from HTTP to HTTPS. It’s 2019 and HTTPS is a no-brainer.
However, if your users are not redirected to the secure HTTPS version, using
HTTPS is of no use. In other words, you’ll need to use an HTTP 301 to switch
between HTTP and HTTPS.
Check the URL bar of your homepage to see if the 301 redirect works between
your two versions. The following is what you’ll see:
https://www.technologycrowds.com/
Enter the URL
https://www.technologycrowds.com/ by removing the «s» from the beginning. A redirect to the secure HTTPS
version of your site should occur if all goes well.
Get rid of all of the 301 redirects on your website
To better crawl your site, Google consults your
sitemap
file. However, since your redirected pages don’t exist, Google has no reason
to crawl them.
301 error status codes can be removed by performing the following steps:
Yourdomain.com/sitemap.xml can be found at this location (keep in mind that
your sitemap URL might be different as there are exceptions).
Use a URL Extractor to download a list of all of your URLs in one place.
- Use any free tool to paste the list.
- Use a 301 status code to narrow the results.
- Replace the 301 URLs in the sitemap file with the final URL.
- Delete the 301 URLs from the sitemap file.
- Redirect chains are to be avoided at all costs.
When the original URL and the final URL are connected by more than one
redirect, this is known as a redirect chain. If you want to see an example of
this, look at Page 1. Nevertheless, Google cautions against the use of
redirect chains, citing the negative impact on user experience (UX) and the
resulting slowdown on site performance.
Link farms are bad for SEO, too. Only about 85% of link equity is passed
through 301 redirects, according to industry estimates. In other words, the
more redirects there are, the worse the situation.
Ensure that the final URL is redirected to. A few pointers:
Redirect chains can be found using a tool like this.
The redirect chain should be replaced with a single 301 redirect once you’ve
found them. In place of Page 1, Page 2, and then Page 3, the redirect goes to
Page 1 and then Page 3.
In addition, you can replace internal links to redirected pages with direct
links to the final URL.
Remove redirect loops
URLs that are linked together can create a redirect loop when one of them
redirects users back to another URL. There are many examples of this, such as
the following:
As soon as possible, you’ll want to address this problem.
Use a free tool to scan up to 100 URLs for errors indicating that the maximum
number of redirects has been exceeded.
You can fix redirect loops in two ways once you find them:
If you don’t want the URL to redirect, change the HTTPS response code to
200.
You should fix the final destination URL if the URL is supposed to reroute.
Your redirects need to be fixed.
If a link is broken, it takes you to a page that doesn’t exist! Page 1 (301)
> Page 2 (302), for example (404). Your website’s search engine rankings
and user experience could suffer as a result.
To check for broken redirects in batches of 100, use the tool we mentioned
above.
You can fix any errors you find by:
- Reviving a long-dead page
- Deleting the redirected URL’s in-links.
Redirects from 302 to 301 should be used instead.
If you want to move permanently, you should never use 302 redirects. Removing
or replacing an HTTP response status code 302 redirect that is in place
because of a long-term move is the best course of action.
301 redirect pages that receive traffic should be examined.
This code tells the browser that a page has permanently relocated to a new
URL. There should be no organic traffic to that page. Chances are that Google
will notice the HTTP 301 if you recently added it.
Use a tool like Moz, SemRush, or Ahrefs to look for redirected pages that are
still receiving organic traffic.
Remove the pages from your sitemap and re-submit them through Google Search
Console once you’ve located them.
The most important things to remember
A 301 redirect is a permanent way of sending a URL to a new location. Search
engines and website visitors alike will be alerted to the URL’s new location
if you do this.
You must have a strategy in place and use redirects wisely. Organic traffic
can be greatly increased by correctly implementing HTTP 301. Follow the advice
above if you’re concerned that your website has unresolved 301 Moved
Permanently errors.
The target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.
The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server’s response payload usually contains a short hypertext note with a hyperlink to the new URI(s).
Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 Temporary Redirect status code can be used instead.
A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls1.
- 1 Calculating Heuristic Freshness RFC7234 Section 4.2.2
- Source: RFC7231 Section 6.4.2
301 CODE REFERENCES
Rails HTTP Status Symbol :moved_permanently
Go HTTP Status Constant http.StatusMovedPermanently
Symfony HTTP Status Constant Response::HTTP_MOVED_PERMANENTLY
Python2 HTTP Status Constant httplib.MOVED_PERMANENTLY
Python3+ HTTP Status Constant http.client.MOVED_PERMANENTLY
Python3.5+ HTTP Status Constant http.HTTPStatus.MOVED_PERMANENTLY
.NET HttpStatusCode.MovedPermanently
Rust http::StatusCode::MOVED_PERMANENTLY
Java java.net.HttpURLConnection.HTTP_MOVED_PERM
Apache HttpComponents Core org.apache.hc.core5.http.HttpStatus.SC_MOVED_PERMANENTLY
Angular @angular/common/http/HttpStatusCode.MovedPermanently
301 status code example
Here’s an example of a request and response for a 301 status code:
Request
GET /old-page.html HTTP/1.1
Host: example.com
Response
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page.html
Content-Length: 0
In this example, the client sends a GET request for an old page located at “/old-page.html” on the host “example.com”. The server responds with a 301 status code, indicating that the requested resource has been permanently moved to a new location, and providing the new URL in the “Location” header. The client should follow this new URL in order to retrieve the resource, and the server sends a “Content-Length” header with a value of 0 to indicate that there is no content in the response body.
How to fix a 301 redirect
To troubleshoot and fix a 301 redirect, you can follow these steps:
- Identify the redirect: Use a web browser and navigate to the old URL that is being redirected. Check the HTTP status code returned by the server using the developer tools or a tool like Screaming Frog SEO Spider. A 301 redirect will return a status code of 301.
- Check the redirect destination: Make sure that the destination URL is correct and functional. Ensure that the new page or website is loading correctly and that there are no errors.
- Update links and references: Update any internal or external links, bookmarks, or references to the old URL with the new URL.
- Implement the redirect: If the redirect is not yet implemented, use server-side configuration or web application code to set up the redirect. This can be done using a .htaccess file or a server-side script. Make sure that the redirect is set up correctly and that it is returning the correct HTTP status code.
- Test the redirect: Use a web browser and navigate to the old URL again. Check the HTTP status code returned by the server and make sure that it is now returning a 301 redirect to the new URL.
- Monitor for issues: Monitor web analytics and search engine rankings to ensure that the redirect is working correctly and that there are no negative impacts on traffic or rankings.
By following these steps, you can troubleshoot and fix a 301 redirect to ensure that users can still find the content they are looking for and that search engine rankings are maintained.
FAQs about 301 redirects
Learn more about 301 redirects with these FAQs:
What causes a 301 redirect?
A 301 redirect is caused by a server or website administrator changing the URL of a web page or website, either by moving the content to a new URL or by updating the website’s structure or architecture. This can happen for a variety of reasons, such as rebranding, consolidating content, or improving the site’s search engine optimization (SEO).
By using a 301 redirect, the administrator informs both users and search engines that the content has been permanently moved to a new location, and any links or bookmarks to the old URL should be updated to the new URL. This helps to ensure that users can still find the content they are looking for and that search engines can update their indexes accordingly.
When should you use a 301 redirect?
A 301 redirect should be used when a web page or website is permanently moved to a new URL.
This is typically done to maintain the page’s search engine rankings and to ensure that users can still find the content they are looking for. A 301 redirect is the best way to inform search engines that the content has been permanently moved to a new location, and that any links or bookmarks to the old URL should be updated to the new URL.
Some common situations where a 301 redirect might be used include:
- Website rebranding
- Website restructuring
- Content consolidation
It is important to ensure that the redirect is implemented correctly to avoid any negative impact on search engine rankings and user experience.
When should you not use a 301 redirect?
A 301 redirect should not be used in certain situations, such as:
- Temporary redirects: If the move is temporary, a 302 or 307 redirect should be used instead of a 301 redirect.
- Redirect chains: Avoid setting up a series of multiple redirects, also known as redirect chains, as they can slow down page load times and cause issues with search engine rankings.
- Incorrect use of redirects: Avoid using redirects as a substitute for proper page content or design. A redirect should be used only to send users to the correct page.
- Domain changes: If there is a domain name change, it may be more appropriate to use a domain level redirect, such as a 301 redirect at the DNS level, instead of a URL level 301 redirect.
In summary, a 301 redirect should not be used in situations where it is not appropriate or where other types of redirects are more suitable. It is important to use the appropriate redirect type to ensure that users and search engines are directed to the correct page and that there are no negative impacts on website traffic or rankings.
What is the difference between a 301 and 302 status code?
A 301 status code is a permanent redirect to a new URL, while a 302 status code is a temporary redirect to a new URL. The client should update bookmarks and links for a 301 redirect, but continue to use the old URL for a 302 redirect. The difference between the two codes is in their intended meaning and behavior.
Additional resources
- Learn about web development
- Learn about SEO
- Web development services from WebFX
- SEO services from WebFX
- MDN Web Docs
- W3Schools
Return to List of HTTP Status Codes