0

これは、組み込みの Javaと多段階認証スキームを使用して発生したいくつかの問題のフォローアップ投稿です。com.sun.net.httpserver.HttpServer

大量のデータを送信すると、Java クライアントが初期の「Authorization required」メッセージを受信できなくなることが示唆されました(Java が I/O をブロックしているため)。

これが、HTTP が 100 ステータス コード ( RFC 2616 )を含む「expect-continue ハンドシェイク」を定義する理由です。

100 (Continue) ステータスの目的は、クライアントがリクエスト本文を送信する前に、オリジン サーバーが (リクエスト ヘッダーに基づいて) リクエストを受け入れる意思があるかどうかを、リクエスト本文を含むリクエスト メッセージを送信しているクライアントが判断できるようにすることです。 . 場合によっては、サーバーが本文を確認せずにメッセージを拒否する場合、クライアントが本文を送信することは不適切または非常に非効率的である可能性があります。

したがって、この場合、データを送信することは適切ではありません。サーバー...

100 (Continue) ステータスで応答して入力ストリームからの読み取りを続行するか、最終ステータス コードで応答する必要があります。

残念ながら、Sunはアプリケーションを介さずにHttpServer常に 100 ステータス コードで応答します。ソースを見る：

/* check if client sent an Expect 100 Continue.
 * In that case, need to send an interim response.
 * In future API may be modified to allow app to
 * be involved in this process.
 */
String exp = headers.getFirst("Expect");
if (exp != null && exp.equalsIgnoreCase ("100-continue")) {
    logReply (100, requestLine, null);
    sendReply (
        Code.HTTP_CONTINUE, false, null
    );
}

アプリケーションが関与していない場合、そのメッセージを送信するのは不適切であることをクライアントに伝えることができないように思われるため、プロトコルに違反しています (これは、接続が早期に閉じられたり、パイプが壊れたりするなどの問題につながります)。何かが足りない場合に備えて、この解釈が正しいかどうかコミュニティに尋ねたほうがいいです:)

4

1 に答える 1

1

サーバーとアプリケーション間の通信はプロトコルの一部ではなく、サーバーとクライアント間の通信のみであるため、プロトコルに違反しているとは言えません。100-Continue を送信した後、サーバーがクライアント要求全体を受け入れる限り、プロトコルは尊重されます。

もちろん、自動的に 100-Continue を返すことは、Expect-Continue が提供することを意図した潜在的な効率向上を失うことを意味しますが、効率はプロトコルが保証するものではありません。

于 2012-02-08T16:08:57.927 に答える