gwan_1 (v3.3.28)を実行し、ページhttp://.../?persistence.cにアクセスしました。対応が早かったです。
しかし、「return 200;」を変更したとき コードの" return 9;" に対して、ブラウザの応答が遅くなり、約 4 秒後に応答しました。
ドキュメントでは、次のように述べられています。
HTTP ヘッダーのオートコンプリートを防ぐには、サーブレットが無効な値を返すようにします。 1 ～ 99 の範囲 (両端を含む) の HTTP ステータス コード。それは動作しますが、非常にゆっくりです。
これについて何か考えはありますか？それはバグですか、それとも何か間違ったことをしましたか?
1、9、および 99 を返そうとしました。すべて同じ結果が得られます。
ついにできた。
これはgwanが原因ではありません。
これはブラウザの動作です。
xbuf_frurl（）を使用してpersistence.cをロードしましたが、応答は約0.35ミリ秒でした。（CPU E2180）
インターネットブラウザはサーバーの応答を待機しています。これはクライアントのタイムアウトです。
この特定のケースでは、サーバーは応答の長さを提供しないためHTTP headers（1-99サーブレットの戻り値は「HTTPヘッダーが欠落している場合は注入しない」ことを意味するため）、クライアントはすべてが送信されます（その時点で結果が表示されます）。
JSONとAJAX（Javascript）を使用してインターネットブラウザーと通信する場合、形式の解釈が異なるため（JSON VS HTTP）、HTTPヘッダーなしで応答を送信できます。
G-WAN comet.cデモでは、ブラウザとのプレーンテキストメッセージパッシング交換を使用しています。これは、クライアント側のJavascriptコードが、サーバーの応答時間を読み取るためです（この特定のアプリケーション用に作成された形式を使用）。