0

私は Alex Maccaw のこの投稿を読んでいました。彼は次のように述べています。

最後の問題は、並行して送信される Ajax リクエストに関するものです。ユーザーがレコードを作成し、すぐに同じレコードを更新すると、2 つの Ajax リクエスト ( POSTと PUT ) が同時に送信されます。ただし、サーバーが「作成」リクエストの前に「更新」リクエストを処理すると、異常になります。レコードがまだ作成されていないため、どのレコードを更新する必要があるかわかりません。

これに対する解決策は、Ajax リクエストをパイプライン処理して、シリアルに送信することです。Spine はデフォルトでこれを行い、一度に 1 つずつ送信されるようにPOST、 PUT 、および DELETE Ajax リクエストをキューに入れます。次のリクエストは、前のリクエストが正常に返された後にのみ送信されます。

しかし、HTTP 仕様のSec 8.1.2.2 Pipeliningには次のように書かれています。

クライアントは、非冪等メソッドまたは非冪等メソッド シーケンスを使用してリクエストをパイプライン処理するべきではありません (セクション 9.1.2 を参照)。そうしないと、トランスポート接続が途中で終了し、不確定な結果になる可能性があります。

では、Spine は本当に POST を「パイプライン化」しますか?

4

1 に答える 1

3

「パイプライン化」という用語の Maccaw の使用法と HTTP 仕様の使用法は、ここでは同じではありません。実は、彼らは正反対です。

HTTP 仕様では、「パイプライン化」という用語は、応答を待たずに複数の要求を送信することを意味します。 セクション 8.1.2.2 を参照してください

永続的な接続をサポートするクライアントは、その要求を「パイプライン化」できます (つまり、各応答を待たずに複数の要求を送信できます)。

この定義に基づいて、パイプライン化されたリクエストの 1 つがアプリの状態を変更し、予期しない結果が生じる可能性があるため、仕様が冪等でないリクエストのパイプライン化を強く推奨しない理由がわかります。

Maccaw がスパインの「パイプライン化」について書いているとき、彼は実際には、HTTP 仕様に従って、クライアントが応答を待たずにリクエストを「パイプライン化」するという事実に対する解決策について言及しています。つまり、spinejs はリクエストをキューに入れ、連続して送信します。連続する各リクエストは、前のリクエストが完了した後にのみ行われます。

于 2013-04-30T00:21:40.310 に答える