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

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

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

10.3.1 300 разнообразного выбора

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

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

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

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

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

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

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

Если 301 код состояния получен в ответ на запрос кроме, ДОБИРАЮТСЯ или НАПРАВЛЯЮТСЯ, агент пользователя не ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, так как это могло бы изменить условия, при которых был выпущен запрос.

  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. Так как перенаправление могло бы быть изменено при случае, клиент ДОЛЖЕН продолжить использовать URI запроса для будущих запросов. Этот ответ является только кэшируемым, если обозначено Управлением Кэша или Истекает поле заголовка.

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

Если 302 кода состояния получены в ответ на запрос кроме, ДОБИРАЮТСЯ или НАПРАВЛЯЮТСЯ, агент пользователя не ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, так как это могло бы изменить условия, при которых был выпущен запрос.

  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 ответа, выполняя Получение на значении поля Местоположения независимо от исходного метода запроса. Коды состояния 303 и 307 были добавлены для серверов, которые хотят сделать однозначно ясным, какой вид реакции ожидается клиента.

10.3.4 303 посмотрите другой

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

Другой URI ДОЛЖЕН быть дан полем Location в ответе. Если метод запроса не был ГОЛОВОЙ, объект ответа ДОЛЖЕН содержать короткое примечание к гипертексту с гиперссылкой к новому 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 не измененный

Если клиент выполнил, условное выражение ПОЛУЧАЮТ запрос, и доступ предоставляется, но документ не был изменен, сервер ДОЛЖЕН ответить этим кодом состояния. 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), ответ не ДОЛЖЕН включать другие заголовки объекта. Иначе (т.е. условное выражение Привыкают слабый блок проверки допустимости), ответ не ДОЛЖЕН включать другие заголовки объекта; это предотвращает несоответствия между кэшируемыми телами объекта и обновленными заголовками.

Если 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. Так как перенаправление МОЖЕТ быть изменено при случае, клиент ДОЛЖЕН продолжить использовать URI запроса для будущих запросов. Этот ответ является только кэшируемым, если обозначено Управлением Кэша или Истекает поле заголовка.

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

Если 307 кодов состояния получены в ответ на запрос кроме, ДОБИРАЮТСЯ или НАПРАВЛЯЮТСЯ, агент пользователя не ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, так как это могло бы изменить условия, при которых был выпущен запрос.

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

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

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