Який код стану http повинен використовуватись, щоб повідомити клієнту, що час очікування закінчився?

На веб-сторінці він використовує менеджер з'єднань YUI / джерело даних для надсилання запитів AJAX на сервер, якщо сеанс (який містить інформацію про те, чи був аутентифікований користувач) вже закінчився, відповіді ajax, які можна переглянути лише автентифікованими користувачі повинні повернути код стану http, повідомивши клієнту, що час сеансу вже закінчився, тоді клієнт або просто перенаправляє його на сторінку входу, або запитує, чи хоче він продовжити сеанс.

Моє питання полягає в тому, що в цій ситуації який код стану http є найбільш доречним, щоб повідомити клієнту, що час сеансу закінчився?

Список кодів стану HTTP з wiki

Найкраще, що я можу запропонувати - це код стану HTTP 401 із заголовком WWW-Authenticate.

Проблема з 403 запитами полягає у RFC 2616, яка говорить: "Авторизація не допоможе, і запит НЕ ПОВИНЕН повторюватися." (тобто не має значення, автентифіковані ви чи ні, ви ніколи не отримаєте доступ до цього ресурсу).

Проблема із запитом 401 полягає в тому, що вони "ПОВИННІ включати поле заголовка автентифікації WWW". Як хтось зазначав , не видається порушенням специфікації використання користувацького значення в заголовку WWW-Authenticate.

Я не бачу жодної причини в RFC 2617, чому статус HTTP 401 у поєднанні зі спеціальним заголовком автентифікації WWW, як це, не буде нормальним:

WWW-Authenticate: MyAuthScheme realm="http://example.com"

Специфікація oAuth насправді, здається, робить саме це, оскільки вони рекомендують це (хоча вони, на мою думку, мають дивну інтерпретацію RFC):

WWW-Authenticate: OAuth realm="http://server.example.com/"

RFC, здається, не є САНКЦІОНОВАНИМ, але насправді я не бачу, що це заборонено (воно, здається, не суперечить жодним умовам ПОВИННО або НЕ ПОВИННО, ПОВИННО чи НЕ ПОВИННО).

Я хотів би, щоб був більш конкретний код стану HTTP для таймаутів і для таких речей, як маркери CSRF, недійсні, щоб це було зрозуміліше.

Я б порекомендував HTTP 401.

Тоді як 403 в основному говорить: "Вам не дозволено, їдьте і не повертайтеся", 401 говорить: "Ми не знаємо, дозволено вам чи ні, тому що ви не принесли свого посвідчення. дістати і спробувати ще раз ".

Порівняйте визначення Вікіпедії :

HTTP 403 - Запит був законним, але сервер відмовляється відповідати на нього.

HTTP 401 - Подібно до 403 заборонено, але спеціально для використання, коли автентифікація можлива, але не вдалася або ще не надана.

Що стосується 419 - це не є стандартним, але опис у Вікіпедії, здається, відповідає:

419 Час очікування автентифікації

419 Час очікування автентифікації, який не є частиною стандарту HTTP, означає, що термін дії автентифікації минув. Він використовується як альтернатива 401 Unauthorized, щоб відрізняти клієнтів, яким інакше автентифіковано відмовлено у доступі до певних ресурсів сервера.

Я вважаю, що відповідним кодом буде 403 / Заборонено. Немає таких, які безпосередньо пов’язані із сесіями.

По правді кажучи, не існує стандартного коду стану HTTP для часу очікування сеансу. Сеанси реалізовані на рівні програми, а не на транспортному рівні HTTP.

Існує спеціальний код стану, який Microsoft використовував для часу очікування сеансу: 599, або просто складіть власний код стану в діапазоні 5xx.

З Вікі з кодами стану:

599 Помилка таймауту підключення до мережі (невідомо) Цей код стану не вказаний у жодних RFC, але використовується проксі-серверами Microsoft Corp. HTTP для сигналізації про час очікування мережевого підключення позаду проксі для клієнта перед проксі.

Я використовую власний код стану 599 для часу очікування сеансу, а потім перевіряю його у відповіді AJAX.

Відповідно до посилання Вікіпедії на коди статусу Http, надані Бобо:

440 Login Timeout (Microsoft)

    A Microsoft extension. Indicates that your session has expired.

Коли ви публікуєте посилання, у цьому посиланні я знайшов цей код стану HTTP 440 . Ви можете використовувати код статусу HTTP 440 для закінчення терміну дії сеансу.

440 Час очікування входу

 The client's session has expired and must log in again.

401 Несанкціоновано ми можемо використовувати, коли облікові дані користувача невірні. або маркер автентифікації, переданий у заголовку, недійсний.

403 Заборонено, ми можемо використовувати це, коли користувач не має конкретного дозволу на запитуваний ресурс.

Отже, на мою думку, ми повинні використовувати 440 Час очікування для входу .

Технічно прийнята відповідь, звичайно, є правильною: якщо ви вже точно знаєте, що збираєтеся не виконати запит, і запитуєте, який код відмови повернути, то відповідним є HTTP 401 "Несанкціонований (неавторизований)", щоб запросити повторну автентифікацію.

Але перш за все, запитайте себе: чи не можна пропустити запит?

Враховуйте, що користувач може просто відвідувати загальнодоступну сторінку вашого веб-сайту, і в цьому випадку ви збираєтеся ляпати їх по обличчю написом "Несанкціоновано!" повідомлення та вимагати від них повторної автентифікації, щоб побачити сторінку, яку вони зазвичай могли б бачити без автентифікації. Це не круто.

Моя порада - ігнорувати той факт, що маркер сеансу невідомий, а просто продовжувати генерувати новий маркер сеансу та створювати для нього новий сеанс. Початковий стан сеансу, звичайно, буде "ще не аутентифікованим", тому, якщо користувач намагається отримати доступ до непублічної сторінки, сторінка подбає про те, щоб він отримав HTTP 401 "Несанкціонований (неаутентифікований) "і повинен пройти автентифікацію. Але якщо користувач потрапляє на загальнодоступну сторінку, він не помітить нічого іншого.

Я б використав відповідь переадресації 302 із заголовком "Location", що спрямовує на шлях до ресурсу, наприклад "/ auth-required"

Клієнт може направити шлях ресурсу до модального за допомогою форми логіна / пароля, уникаючи перекладу користувача на іншу сторінку.

Для запитів, що не стосуються 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
});

Код 408. "Час очікування запиту" здається ідеальним - RFC 2616 пояснює, що це означає

Клієнт не подав запит протягом часу, коли сервер був готовий до очікування.

тобто, саме "тайм-аут", як вам потрібно!