11

Delphi では、 HTTP 経由でデータを送受信するためにIndy を使用しTIdHTTPWebBrokerBridgeています。TIdHTTPサーバーでは、手の込んだ処理はありません。常に単純なコンテンツ ストリームで応答するだけです。問題がある場合は、応答コンテンツでその問題に関する情報のみを返します (認証の失敗、無効な要求など)。では、クライアント側では、このサーバーへのリクエストが成功すると、常にレスポンス コード 200 (OK) が返されると想定できますか?

クライアントでは、リクエストが成功した場合にブール値のみを返す関数内にリクエストがラップされているため、私は疑問に思っています。

この関数内:

IdHTTP.Get(SomeURL, AStream);
Result:= IdHTTP.ResponseCode = 200;

この関数は、データをフェッチする可能性のあるすべてのリクエストを処理します。リクエストに問題があった場合、この関数は False を返す必要があります。私のシナリオでは、サーバー上で常に何らかのコンテンツを返すので、クライアントは常にこの関数で 200 の応答コードを受け取りますか?

本当の問題は、私が常にある種のコンテンツを返し、サーバー上のすべての例外を処理する場合、サーバーは常に各要求に対して 200 のステータス コードを返すのでしょうか?

4

4 に答える 4

17

「成功したすべての HTTP 要求は常にステータス コード 200 を返しますか?」

w3.org: HTTP/1.1 Status Code Definitions( RFC 2616)参照

答えはノーです。2xx はすべて成功したと見なされます。これは、使用するHTTP メソッドに依存する場合があります。

Web サーバー アプリケーションは、成功時に常に 200 を返す必要がありますか? それは、リクエストメソッドとそれがクライアントに向けたシグナルに依存するかもしれません。例えば

メソッドのPUT場合（強調は私のものです）：

既存のリソースが変更された場合、リクエストが正常に完了したことを示すために、200 (OK) または204 (コンテンツなし) の応答コードを送信する必要があります。

メソッドのPOST場合:

POST メソッドによって実行されるアクションは、URI によって識別できるリソースにならない場合があります。この場合、 応答に結果を説明するエンティティが含まれているかどうかに応じて、200 (OK) または204 (コンテンツなし) のいずれかが適切な応答ステータスです。

オリジンサーバーでリソースが作成されている場合、応答 は201 ( Created ) であり、要求のステータスを記述し、新しいリソースを参照するエンティティと、Location ヘッダーを含む必要があります (セクション 14.30 を参照)。このメソッドへの応答は、応答に適切な Cache-Control または Expires ヘッダー フィールドが含まれていない限り、キャッシュできません。ただし、303 (See Other) 応答を使用して、ユーザー エージェントにキャッシュ可能なリソースを取得するよう指示できます。

からわかるように、実装に応じてRCF、すべてのメソッドに独自の成功ステータス コードが必要です。

あなたの他の質問:

「このサーバーへのリクエストが成功すると、常にレスポンス コード 200 (OK) が返されると仮定できますか?」

Web サーバーが常にステータス 200 で応答する場合は、常にステータス コード 200 を期待できます。Web サーバー アプリケーションは、クライアントに返す応答を制御します。

つまり、ステータス コード 200 は HTTP リクエストが成功した場合の標準的なレスポンスです (実際のレスポンスは、使用するリクエスト メソッドによって異なります)。実際の Web サーバーでは、別段の指示がない限り、リクエストが成功したときにデフォルトとして設定する必要があります (レミーの答えで説明されています）。

于 2013-02-28T21:20:54.583 に答える
9

特定の質問に答えるには：

このサーバーへの要求が成功すると、常に応答コード 200 (OK) が返されると仮定できますか?

答えはYesです。これは、自分で別の値で上書きするか、サーバーに別の応答コードでTIdHTTPWebBrokerBridge暗黙TIdHTTPServer的に応答する何かを実行させない限り、すべての要求に対してデフォルトの応答コードを常に 200 に設定するためです ( Redirect()302 を使用するなど)。 、またはSmartServeFile()304 を使用する)、またはTIdHTTPServer4xx または 5xx エラー応答コードを割り当てる原因となるエラーが発生します。

ただし、一般的に、他の人があなたに言ったことは真実です。クライアント側では、200 だけでなく、可能なすべての HTTP 成功応答コードを処理する必要があります。サーバーの実装については何も仮定しないでください。

実際、TIdHTTPすでにそれを処理しています。がTIdHTTPエラー コードと見なす応答コードを検出すると、コードにEIdHTTPProtocolException例外が発生します。したがって、例外が発生しない場合は、応答が成功したと見なしてください。応答コードを手動で確認する必要はありません。

通常は例外を発生させたくない特定の応答コードがある場合は、またはのオプションAIgnoreRepliesパラメータでその値を指定できます。または、最新の Indy 10 SVN リビジョンを使用している場合は、最近新しいフラグがプロパティに追加されたため、応答コードに対して例外は発生しません。TIdHTTP.Get()TIdHTTP.DoRequest()hoNoProtocolErrorExceptionTIdHTTP.HTTPOptionsEIdHTTPProtocolException

于 2013-02-28T22:21:15.583 に答える
2

成功した応答は 2xx List_of_HTTP_status_codesです

于 2013-02-28T20:42:51.567 に答える
1

私は次のことをしました。すべての 200 と LOG 例外をまっすぐに処理します。200以外の単一ではなく、未承認およびタイムアウト（パスワードまたは場合によっては使用できないサーバー）を除いて、機能しました。ただし、幅広いメインストリーム アプリについては、多く/すべての回答が考慮されます。

      while (iRedo < 3) do begin
        s := Self.HTTPComponent.Get( sUrl );

        if self.HTTPComponent.ResponseCode = 200 then begin
          break;
        end;

        // IDEIA - log what happend if not 200
        logWhatHappend( s, HTTPComponent ); // then log content, headers, etc
        inc( iRedo ); sleep( 5 );
      end;
于 2015-10-04T15:50:14.390 に答える