Drupalが403 Forbiddenを使用するのはなぜですか？

HTTP / 1.1を定義するドキュメントであるRFC 2616は、すべてのHTTPステータスコードの定義を示しています。のため403 Forbidden、それは言う：

サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。リクエストメソッドがHEADではなく、サーバーがリクエストが実行されなかった理由を公開したい場合は、エンティティで拒否の理由を説明する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータスコード404（見つかりません）を使用できます。

しかし、それはDrupalがどのように使用するかではありません。場合によっては、コールバック（例shortcut_link_add_inline()：）のデフォルト条件に使用するか、本質403 Forbidden的に「Drupalが要求を理解しない」と同等にするか、またはそれを使用してクライアントに通知しますページにアクセスできません（つまり、匿名ユーザーであるなどの権限が原因です）。

前者（「リクエストが理解されていません」）の場合、より適切なステータスコードは400 Bad Request次のとおりです。

不正な構文のため、サーバーはリクエストを理解できませんでした。クライアントは変更なしでリクエストを繰り返すべきではありません。

後者の場合（「クライアントはアクセス許可のためにページにアクセスできません」）、それは次のいずれかである必要があります401 Unauthorized（Drupalがアクセス許可の問題であることを伝えたい場合）：

リクエストにはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション14.47）を含める必要があります。クライアントは適切なAuthorizationヘッダーフィールド（セクション14.8）を使用してリクエストを繰り返すことができます（MAY）。要求にすでに認証資格情報が含まれている場合、401応答は、それらの資格情報の認証が拒否されたことを示します。

または404 File Not Found（そうでない場合）：

サーバーは、Request-URIに一致するものを検出しませんでした。状態が一時的であるか永続的であるかは示されません。410（Gone）ステータスコードは、内部的に構成可能なメカニズムを通じて、古いリソースが永続的に利用できず、転送アドレスがないことをサーバーが認識している場合に使用する必要があります（SHOULD）。このステータスコードは、サーバーがリクエストが拒否された理由を正確に明らかにしたくない場合、または他の応答が該当しない場合に一般的に使用されます。

鉱山を強調します（の定義の最後の文も参照してください403 Forbidden）。

私はそれが長年にわたってこのようなものであったことに気づきましたが、Drupalが好きではない要求をdrupal_access_denied()受け取った403 Forbiddenときに送信する唯一の応答を作成するための元の理論的根拠は何でしたか。

引用で述べたように、401 UnauthorizedHTTP認証と組み合わせる必要があります。これは、Drupalが使用しているものではないため、これはオプションではありません。

したがって、403はIMHOが完全に有効な応答です。クライアントは要求を繰り返す必要はありませんが、最終的にはログインフォームに入力して別の要求を送信する可能性があるためです。

あなたが投稿したshortlink関数のような特別なケースはそれほど明確ではありません。拒否されたアクセスを使用する理由は、それが一種の認証であるトークンをチェックしているためだと思います。しかし、400または404を使用することもできます。400の代わりに403を使用する理由は、400を返すヘルパー関数がないためだと思います。

プライベートユーザーが匿名ユーザーとしてプライベートメッセージを試行すると、403または404（プライバシー上の理由）が発生するかどうかについて（私が管理している）Privatemsgモジュールについても議論されています。以前は404でしたが、403に変更されました。これは、ユーザーがメール通知の直接リンクをクリックすることが多く、403ページを簡単にログインフォームに変換できるためです（これは、すぐに使用できるモジュールがあるためです）。したがって、これは403の説明の最後の2つの文に関連しています。