セッションがタイムアウトしたことをクライアントに通知するために使用されるはずのhttpステータスコードは何ですか？

Question 1

Webページでは、YUI接続マネージャー/データソースを使用してAJAXリクエストをサーバーに送信します。セッション（ユーザーが認証されているかどうかに関する情報を含む）がすでにタイムアウトしている場合、認証されたユーザーのみが表示できるajax応答ユーザーはhttpステータスコードを返し、セッションがすでにタイムアウトしていることをクライアントに通知する必要があります。その後、クライアントは単にログインページにリダイレクトするか、セッションを延長するかどうかを尋ねます。

私の質問は、この状況で、セッションがタイムアウトしたことをクライアントに伝えるのに最も適切なhttpステータスコードは何ですか？

ウィキからのHTTPステータスコードのリスト

Question 2

私が提案できる最善の方法は、WWW-Authenticateヘッダーを持つHTTP401ステータスコードです。

403リクエストの問題は、RFC 2616に「承認は役に立たず、リクエストを繰り返さないでください」と記載されていることです。（つまり、認証されているかどうかは関係ありません。そのリソースにアクセスすることはありません）。

401リクエストの問題は、「WWW-Authenticateヘッダーフィールドを含める必要がある」と述べていることです。誰かが指摘しているWWW-Authenticateヘッダにカスタム値を使用するための仕様に違反して表示されません。

RFC 2617には、HTTP401ステータスとこのようなカスタムWWW-Authenticateヘッダーを組み合わせても問題がない理由がわかりません。

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

OAuthの仕様は、（彼らは私の心RFCの奇妙な解釈を持っているが）、彼らはこれをお勧めして、実際に、ちょうどこれを行うようです。

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

これはRFCによって明確に認可されているようには見えませんが、実際には禁止されていることはわかりません（MUSTまたはMUST NOT、SHOULDまたはSHOULD NOT条件と競合していないようです）。

タイムアウトやCSRFトークンが無効であるなどの、より具体的なHTTPステータスコードがあればいいのにと思います。

Question 3

HTTP401をお勧めします。

403は基本的に「許可されていない、立ち去って戻ってこない」と言っているのに対し、401は「IDを持ってこなかったので許可されているかどうかはわかりません。行く入手して再試行してください。」

ウィキペディアの定義を比較してください：

HTTP 403-リクエストは正当なリクエストでしたが、サーバーはそれに応答することを拒否しています。

HTTP 401-403 Forbiddenに似ていますが、特に認証は可能であるが失敗したか、まだ提供されていない場合に使用します。

Question 4

419についてはどうですか-それは標準ではありませんが、ウィキペディアの説明は合うようです：

419認証タイムアウト

HTTP標準の一部ではありませんが、419認証タイムアウトは、以前に有効だった認証の有効期限が切れたことを示します。特定のサーバーリソースへのアクセスが拒否されている認証済みクライアントと区別するために、401Unauthorizedの代わりに使用されます。

Question 5

適切なコードは403 / Forbiddenになると思います。セッションに直接関係するものはありません。

Question 6

真実は、セッションタイムアウトのための標準的なHTTPステータスコードはありません。セッションは、HTTPトランスポート層ではなく、アプリケーション層に実装されます。

Microsoftがセッションタイムアウトに使用しているカスタムステータスコードがあります：599、または単に5xxの範囲で独自のステータスコードを作成します。

ステータスコードWikiから：

599ネットワーク接続タイムアウトエラー（不明）このステータスコードはRFCで指定されていませんが、Microsoft Corp. HTTPプロキシによって使用され、プロキシの背後にあるネットワーク接続タイムアウトをプロキシの前のクライアントに通知します。

セッションタイムアウトにカスタムステータスコード599を使用し、AJAX応答でそれを確認します。

Question 7

上記のBoboが提供したHttpステータスコードのウィキペディアリンクによると：

440 Login Timeout (Microsoft)

    A Microsoft extension. Indicates that your session has expired.

Question 8

リンクを投稿すると、そのリンクでこのHTTPステータスコード440が見つかりました。セッションの有効期限が切れた場合は、440HTTPステータスコードを使用できます。

440ログインタイムアウト

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

401ユーザーのログイン資格情報が間違っている場合に使用できる無許可。または、ヘッダーで渡された認証トークンが無効です。

403禁止ユーザーが要求されたリソースに対する特定の権限を持っていない場合にこれを使用できます。

したがって、私の意見では、440ログインタイムアウトを使用する必要があります。

Question 9

技術的には、受け入れられた答えはもちろん正しいです。リクエストが失敗することがすでにわかっていて、どの失敗コードを返すかを尋ねている場合は、HTTP 401「Unauthorized（Unauthenticated）」が適切です。再認証を促すため。

しかし、まず第一に、あなた自身に尋ねてください：あなたは要求に失敗するべきですか？

ユーザーが単にあなたのウェブサイトの公開ページにアクセスしている可能性があることを考慮してください。その場合、あなたは「無許可」で顔を叩きます。メッセージを送信し、認証なしで通常表示できるページを表示するために、再認証を要求します。それはクールではない。

私のアドバイスは、セッショントークンが不明であるという事実を無視し、単に新しいセッショントークンの生成に進み、そのための新しいセッションを作成することです。もちろん、セッションの初期状態は「まだ認証されていません」であるため、ユーザーが非公開ページにアクセスしようとすると、ページはHTTP 401「Unauthorized（Unauthenticated）」を受信したことを確認します。 "そして認証する必要があります。しかし、ユーザーが公開ページにアクセスした場合、ユーザーは何も変わったことに気付くことはありません。

Question 10

「/ auth-required」のようなリソースパスに向ける「Location」ヘッダーを使用して、302リダイレクト応答を使用します

クライアントは、ログイン/パスワードフォームを使用してリソースパスをモーダルにルーティングし、ユーザーを別のページに転送することを回避できます。

Question 11

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
});

Question 12

コード408。「リクエストタイムアウト」は完璧のようです-RFC2616はそれが意味することを説明しています

サーバーが待機する準備ができている時間内に、クライアントは要求を生成しませんでした。

つまり、必要に応じて、まさに「タイムアウト」です。