このコンセプトに関するあなたの意見/コメントを知りたいと思います。代替案がある場合は？これが実現可能か有益か？アイデア：単一のHTTPリクエストを使用して複数のhttpレスポンスを生成
私の理解によると、httpリクエストごとに、サーバーは何らかの操作を実行し、http応答を返します。
ここで、サーバー上で実行されているプロセスをより詳細に制御したい場合のシナリオを考えてみましょう。
状況1：httpリクエスト送信 - >サーバー開始処理（処理中の長いタスク） - >ユーザーがブラウザを閉じます。 ここでもプロセスは実行され、サーバーを消費し、http応答はクライアントで無視されます。
ここでリソースが無駄になります。
状況2：HTTPリクエストの送信 - >サーバが処理を開始する（プロセスで長いタスク）
ここでは、クライアントは、サーバで実行中のプロセスの状態を認識しません。 クライアントはHTTP応答を返すまで待たなければなりません。
私の考え方：最初のhttpリクエストと最後のhttpレスポンスの間に、複数の中間的なhttpレスポンスを送信する機能を追加します。このレスポンスは、サーバー側で実行中のプロセスに関する情報を運びます。
状況1に対処：HTTPリクエストの送信 - >サーバ開始処理（プロセスで長いタスク） - > [中間HTTPレスポンスとしてプロセスIDを返す] - >ユーザがブラウザを閉じる - > [送信プロセスIDを使用してサーバープロセスを終了するhttp要求]
状況への解決2：http要求送信 - >サーバーが処理を開始します（処理中の長いタスク） - > [実行中のプロセスの詳細でhttp応答を返します。 [間隔でサーバー] - > [必要に応じて任意の操作を実行]
親切にコメント:)と私は何かが不足している場合は正しい。
これは一般的に202 Acceptedを 'Location'ヘッダで返すことで行われ、結果を探す場所を教えてくれます。進行中の更新が必要な場合は、WebSocketsを使用します。独自のHTTPを定義することは、おそらく効果的なルートの転送ではないため、SOは本当にそのプロセスであなたを助けることはできません。我々は議定書を担当していない。 – jonrsharpe
これはきれいで簡単です。行って、それを実装してください。 –
@RolandIllig私は、タスクの大きさを明確に理解していないときには、「やるよ」とOPを送信するのが特に建設的だとは思わない。 – jonrsharpe