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

Question

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

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

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

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

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

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

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

10.3.2 301 постоянно перемещено

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

ДОЛЖЕН быть указан новый постоянный URI по полю Расположение в ответе. Если метод запроса не был 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 ДОЛЖЕН быть предоставлен поле Расположение в ответе. Если метод запроса не был 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 ДОЛЖЕН быть задан поле Расположение в ответе. Если метод запроса не был 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

сервер без учета часов правила, а прокси и клиенты добавляют своя дата для любого ответа получил без одного (как уже определено в [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 Использовать прокси

Запрашиваемый ресурс ДОЛЖЕН быть доступ через прокси, данный поле Местоположение. Поле Местоположение дает 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 ДОЛЖЕН быть предоставлен поле Расположение в ответе. Если метод запроса не был HEAD, субъект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылка на новый URI, так как многие пользовательские агенты до HTTP / 1.1 не понять статус 307. Следовательно, примечание ДОЛЖНО содержать информация, необходимая пользователю для повторить первоначальный запрос на новый URI.

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Как думать о кодах состояния HTTP от Mark Nottingham

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

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

WWW-Authenticate: realm =

Носитель, OAuth, Basic, Digest, Cookie и т. Д.

• Схема аутентификации протокола передачи гипертекста (HTTP) Registry
• HTTP-аутентификация на основе файлов cookie - DRAFT

Answer 3

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

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

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

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

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

Увидимся.

Answer 4

У меня были редкие случаи, когда браузер Firefox кэшировал редирект 302. Вот почему я использую 307 для страниц входа и, например, перенаправляет на самую новую статью / пост / комментарий / и т. д.

Если вы используете 302, не забудьте дважды проверить, что кэширование отключено:

header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-cache');
header('Pragma: no-cache');
header('Cache-Control: post-check=0, pre-check=0', false);