Какой правильный код состояния HTTP при перенаправлении на страницу входа?

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

Я спрашиваю, потому что ни один из кодов ответов 3xx, установленных W3C, похоже, не соответствует требованиям:

10.3.1 300 множественных выборов

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

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

агент пользователя, выбор наиболее подходящего варианта МОЖЕТ быть выполнен автоматически. Однако эта спецификация не определяет никаких стандартов для такого автоматического выбора.

Если у сервера есть предпочтительный выбор представления, он ДОЛЖЕН включить конкретный URI для этого представления в поле Location; пользовательские агенты МОГУТ использовать значение поля Location для автоматического перенаправления. Этот ответ кэшируется, если не указано иное.

10.3.2 301 перемещено навсегда

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

Новый постоянный URI ДОЛЖЕН быть задан в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый URI.

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

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request.

10.3.3 302 найдено

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

Временный URI ДОЛЖЕН быть задан в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый URI.

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

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it

были ответом 303, выполняющим GET для значения поля Location независимо от исходного метода запроса. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно прояснить, какой тип реакции ожидается от клиента.

10.3.4 303 См. Другое

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

Другой URI ДОЛЖЕН быть указан в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый URI.

  Note: Many pre-HTTP/1.1 user agents do not understand the 303
  status. When interoperability with such clients is a concern, the
  302 status code may be used instead, since most user agents react
  to a 302 response as described here for 303.

10.3.5 304 Не модифицировано

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

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

  - Date, unless its omission is required by section 14.18.1 If a

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

  - ETag and/or Content-Location, if the header would have been sent
    in a 200 response to the same request
  - Expires, Cache-Control, and/or Vary, if the field-value might
    differ from that sent in any previous response for the same
    variant If the conditional GET used a strong cache validator (see

раздел 13.3.3), ответ НЕ ДОЛЖЕН включать другие заголовки объектов. В противном случае (т. Е. Условный GET использовал слабый валидатор), ответ НЕ ДОЛЖЕН включать другие заголовки объекта; это предотвращает несоответствия между кэшированными сущностями и обновленными заголовками.

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

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

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

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

  Note: RFC 2068 was not clear that 305 was intended to redirect a
  single request, and to be generated by origin servers only.  Not
  observing these limitations has significant security consequences.

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

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

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

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

Временный URI ДОЛЖЕН быть задан в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый URI, поскольку многие пользовательские агенты до HTTP / 1.1 не понимают статус 307. Следовательно, примечание ДОЛЖНО содержать информацию, необходимую пользователю, чтобы повторить исходный запрос на новом URI.

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

Я использую 302 сейчас, пока я не найду правильный ответ.

Обновление и заключение:

HTTP 302 лучше, поскольку, как известно, лучше всего совместим с клиентами / браузерами.

Я бы сказал 303 см. Другие 302 Найдено:

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

на мой взгляд, наиболее точно соответствует странице входа. Сначала я подумал, 303 see otherчто сработает так же хорошо. После некоторых размышлений я бы сказал, что 302 Foundэто более уместно, потому что запрошенный ресурс был найден, просто нужно пройти еще одну страницу, прежде чем к ней можно будет получить доступ. По умолчанию ответ не кэшируется, что тоже нормально.

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

Вы должны сделать перенаправление на стороне клиента, например, с помощью javascript. код состояния для перенаправления, поскольку требуемая авторизация не существует . Использование 30x для этого не соответствует HTTP.

Как думать о кодах состояния HTTP, Марк Ноттингем

401 Неавторизованный запускает механизм аутентификации запроса HTTP.

401 Unauthorizedкод состояния требует наличия WWW-Authenticateзаголовка, который поддерживает различные типы аутентификации:

WWW-аутентификация: <тип> область = <область>

Bearer, OAuth, Basic, Digest, Cookie и т. Д.

• Реестр схемы проверки подлинности протокола передачи гипертекста (HTTP)
• HTTP-аутентификация на основе файлов cookie - ПРОЕКТ

Я считаю, что подходящим решением является заголовок HTTP 401 (Not Authorized).

http://en.wikipedia.org/wiki/HTTP_codes#4xx_Client_Error

Цель этого заголовка именно в этом. Но вместо перенаправления на страницу входа правильный процесс будет выглядеть примерно так:

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

Это хорошая практика, например, предоставление полезной страницы 404 со ссылками на карту сайта и формой поиска.

Увидимся.