Когда пользователь не вошел в систему и пытается получить доступ к странице, требующей входа в систему, каков правильный код состояния 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 aClockless 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 лучше, поскольку, как известно, лучше всего совместим с клиентами / браузерами.