Какой код статуса http должен использоваться, чтобы сообщить клиенту, что время ожидания сеанса?
На веб-странице он использует диспетчер соединений/источник данных YUI для отправки запросов AJAX на сервер, если сеанс (который содержит информацию о том, был ли пользователь аутентифицирован) уже отключен, эти ajax-ответы, которые могут быть только просматриваемые аутентифицированными пользователями, должны возвращать код состояния http, сообщая клиенту, что сеанс уже вычислен, и клиент либо просто перенаправляет его на страницу входа в систему, либо спрашивает его, хочет ли он продлить сеанс.
Мой вопрос в том, что в этой ситуации, какой код статуса http наиболее подходит для того, чтобы сообщить клиенту, что сеанс имеет время ожидания?
Список кодов состояния HTTP из вики
Ответы
Ответ 1
Лучше всего я могу предложить код статуса HTTP 401 с заголовком WWW-Authenticate.
Проблема с 403 запросами - это RFC 2616: "Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться". (т.е. не имеет значения, если вы аутентифицированы или нет, вы не будете получать доступ к этому ресурсу когда-либо).
Проблема с запросами 401 заключается в том, что они "ДОЛЖНЫ включать поле заголовка WWW-Authenticate". Как отметил кто-то отметил, он не нарушает спецификацию, чтобы использовать пользовательское значение в заголовке WWW-Authenticate.
Я не вижу никакой причины в RFC 2617, почему статус HTTP 401 в сочетании с настраиваемым заголовком WWW-Authenticate, подобным этому, не будет все в порядке:
WWW-Authenticate: MyAuthScheme realm="http://example.com"
oAuth spec на самом деле, похоже, делает именно это, поскольку они рекомендуют это (хотя они имеют в виду нечетную интерпретацию RFC)
WWW-Authenticate: OAuth realm="http://server.example.com/"
Это, по-видимому, не имеет особого смысла в RFC, но я не могу видеть, что он запрещен им (он, похоже, не конфликтует с каким-либо ДОЛЖНЫМ или НЕ ДОЛЖЕН, ДОЛЖЕН или НЕ ДОЛЖЕН быть в состоянии).
Я бы хотел, чтобы был более конкретный код состояния HTTP для тайм-аутов, а для таких вещей, как токены CSRF, были недействительными, так что это было яснее.
Ответ 2
Я бы порекомендовал HTTP 401.
В то время как 403 в основном говорит: "Тебе не разрешают, уходят и не возвращаются", 401 говорит: "Мы не знаем, разрешено ли вам или нет, потому что вы не принесли свои ID. Пойдите, попробуйте еще раз.
Сравните определения Википедии:
HTTP 403. Запрос был юридическим запросом, но сервер отказывается отвечать на него.
HTTP 401 - Подобно 403 Forbidden, но специально для использования, когда возможна аутентификация, но она не удалась или еще не была предоставлена.
Ответ 3
Что насчет 419 - это не стандарт, но описание в Википедии, похоже, соответствует:
419 Тайм-аут аутентификации
Не является частью стандарта HTTP, 419 Тайм-аут аутентификации означает что ранее действительная аутентификация истекла. Он используется как альтернатива 401 Несанкционированная, чтобы отличать от иначе аутентифицированным клиентам отказывают в доступе к определенному серверу ресурсы.
Ответ 4
Я считаю, что соответствующий код будет 403/Запрещен. Нет никаких непосредственных связей с сеансами.
Ответ 5
Правда, нет стандартного кода состояния HTTP для таймаута сеанса. Сеансы реализованы в прикладном уровне, а не в транспортном уровне HTTP.
Существует специальный код состояния, который Microsoft использует для таймаута сеанса: 599 или просто составляет свой собственный код состояния в диапазоне 5xx.
Из кодов состояния Wiki:
599 Ошибка таймаута сетевого соединения (неизвестно) Этот код статуса не указан в каких-либо RFC, но используется прокси-серверами Microsoft Corp. HTTP, чтобы сигнализировать тайм-аут сетевого соединения за прокси-сервером перед клиентом перед прокси-сервером.
Я использую код пользовательского статуса 599 для таймаута сеанса, а затем проверяю его в ответе AJAX.
Ответ 6
Согласно ссылке Википедии кодов состояния HTTP, приведенной выше Бобо:
440 Login Timeout (Microsoft)
A Microsoft extension. Indicates that your session has expired.
Ответ 7
Технически, принятый ответ правильный: если вы уже точно знаете, что будете отказываться от запроса, и вы спрашиваете, какой код отказа возвращается, то HTTP 401 "Unauthorized (Unauthenticated)" является подходящим один, чтобы запросить повторную аутентификацию.
Но прежде всего спросите себя: если вы не выполните запрос?
Учтите, что пользователь может просто посещать общедоступную страницу вашего сайта, и в этом случае вы собираетесь ударить их по лицу "Несанкционированным!". и потребовать повторной аутентификации, чтобы просмотреть страницу, которую они обычно могли бы видеть без проверки подлинности. Это не круто.
Мой совет состоит в том, чтобы игнорировать тот факт, что токен сеанса неизвестен, и просто приступайте к созданию нового токена сеанса и создайте для него новый сеанс. Исходное состояние сеанса, конечно, будет "еще не аутентифицировано", поэтому, если пользователь пытается получить доступ к непубличной странице, страница будет следить за тем, чтобы они получали HTTP 401 "Несанкционированный (не прошедший проверку подлинности)" и должен пройти аутентификацию. Но если пользователь приземляется на общедоступной странице, они не заметят ничего другого.
Ответ 8
Код 408. "Тайм-аут запроса" кажется идеальным - RFC 2616 объясняет, что это означает
Клиент не выдал запрос в течение времени, когда сервер готовы ждать.
i.e, точно "тайм-аут", как вам нужно!
Ответ 9
Для запросов, отличных от Ajax, я использую перенаправление 302.
Для запросов Ajax я использую 200 для известных ошибок. Таким образом, я могу использовать объект данных. Я нахожу, что объект данных легче работать, чем парсинг jqXHR для информации. И тогда мне не нужно беспокоиться о том, какой код состояния HTTP можно попытаться переназначить для моей ситуации.
Пример jQuery:
$.ajax({
//send data to server
})
.done(function(data, textStatus, jqXHR) {
if (data.success) {
//then process return data
}
else {
//get error type or message from data object
//could use custom error codes
}
})
.fail(function(jqXHR, textStatus, errorThrown) {
//handle unknown errors
});