web-dev-qa-db-ja.com

サーバーとクライアントの両方を開発する場合、独自のHTTP応答コードTEXTを使用しない技術的な理由はありますか？

長年にわたって、私はこのサイトで「自分のHTTP応答コードを発明できますか？」という行に沿ってかなりの数の質問を見てきました。通常、サーバーとクライアントの両方を開発している人から尋ねられます。応答は標準的なコードに固執する傾向があります。

標準 HTTPステータスコード番号 を使用する場合、technical複数の501応答を区別するために、カスタムテキストを使用しない理由は何ですか？

繰り返しますが、私の以外のクライアントには、これらの値は表示されません。これらの値は、認証された要求に応じてAJAXによって返されます。

http-response
40
Mawg says reinstate Monica

別のアプローチは、たとえばJSONオブジェクトに、詳細な失敗理由を含む応答本文を含めることです。これは、存在しないWebページが開かれたときにブラウザーに配信されることが多いカスタマイズされた404ページに相当します。

たとえば、バックエンドがPythonでDjangoを使用して記述されている場合、ミドルウェア関数を実装できます（ https://docs.djangoproject.com/en/3.0/topics/を参照）。 http/middleware / ）例外をキャッチし、いくつかのエラーJSONオブジェクトで500エラーを返します（これは完全にテストされていないことに注意してください。これを使用して、どのように実行できるかを把握してください）。

import sys, traceback
from Django.http import JsonResponse

def exception_handling_middleware(get_response):

    def middleware(request):

        try:
            # call inner handler
            return get_response(request)
        except BaseException:
            # if any exception happens, return an error response
            # with a 500 status code
            return JsonResponse(
              {
                "error": str(sys.exc_info()[1]),
                "traceback": traceback.format_exc()
              },
              status=500)
40
Hans-Martin Mosner

「ステータステキスト」はHTTP/2には存在しません。数値コードのみです。したがって、HTTP/2（またはそれ以降のバージョン）を使用することはできません。

HTTP/2を指定するRFC 7540のセクション 8.1.2.4 Response Pseudo-Header Fields によると、

HTTP/2は、HTTP/1.1ステータス行に含まれるバージョンまたは理由フレーズを伝える方法を定義していません。

84
user355880

すべてのクライアントとサーバーを制御できますが、注意が必要な第3の目的、つまり中間体もあります。

中間体は、Webサーバー、プロキシ、キャッシュ、Webアプリケーションファイアウォール、ロードバランサー、CDN、およびクライアントとサーバーの間にあるHTTPメッセージを処理するその他の中間システムです。エンドツーエンドの暗号化を使用して、使用するすべての仲介者を制御する場合でも、標準に固執する場合は、新しい仲介者をシステムに統合する方が一般的に簡単です。

そうは言っても、別の方法で設定しない限り、標準準拠の仲介者は通常、メッセージの処理方法を決定するときにステータスコードのみを使用し、理由フレーズを無視する必要があるため、ほとんどの場合、理由フレーズをカスタマイズしても安全です。理由フレーズは、メッセージの処理方法に影響を与えない人間が読める理由のみを伝えるために予約する必要があります。

RFC 7231（セクション6.1） （私の強調）からのいくつかの参照：

下記のステータスコードは、この仕様、[RFC7232]のセクション4、[RFC7233]のセクション4、および[RFC7235]のセクション3で定義されています。 ここにリストされている理由フレーズは推奨事項のみです-プロトコルに影響を与えることなく、ローカルの同等のものに置き換えることができます。

そして RFC 7230（セクション3.1.2） （私の強調）から：

Reason-phrase要素は、数値のステータスコードに関連付けられたテキストによる説明を提供することを唯一の目的として存在します。これは主に、インタラクティブテキストクライアントでより頻繁に使用されていた以前のインターネットアプリケーションプロトコルを順守しないためです。 クライアントは理由フレーズの内容を無視する必要があります

では、標準のHTTPステータスコードでは不十分な場合は、代わりに何をすべきでしょうか。

ステータスコードを使用します。 HTTPステータスコードは拡張可能に設計されています。拡張ステータスコードを理解しないクライアントや仲介者との下位互換性を保つ方法でHTTPステータスコードを拡張する方法については、 RFC 7231セクション6 を参照してください。

49
Lie Ryan