0

私は現在、特定のリソースに対する同時 GET リクエストを禁止することが RFC 2616 (特に、GET メソッドに必要な冪等性と安全性プロパティ、§9.1) に違反するかどうかについて議論しています。

例えば; サーバーが GET /data/?dataId=123456 を同時に 2 回受信した場合、一方または両方の要求がエラー メッセージを返すことは、安全性または冪等性の違反と見なされますか?

私の理解によると、RFC では、同じ要求が再度呼び出されたときに同じ結果が得られるように指定されています。ただし、同時リクエストに関してどのような動作が許容されるかについては何も見ていません。

私の感じでは、同時 GET アクセスを許可しないこと (もちろん一般的な規則としてではなく、特定のリソースで) は RFC の違反にはなりません。423 応答コード、または 500 (あまりエレガントではありませんが)、または 429 または 420 (意味は少し異なりますが) を返すことは、私には受け入れられるようです。

ただし、RFCがこの立場を否定していることを証明する有効な議論があるかどうかを知りたい.

よろしくお願いいたします。

4

2 に答える 2

0

運用上、サーバーはリソースを攻撃から保護することに関して好きなことをすることができます。

とはいえ、リソースへの同時 GET を禁止すると、控えめに言っても、多くのクライアントを驚かせるでしょう。

于 2014-02-20T00:26:14.397 に答える
0

9.1.1 安全な方法

特に、GET メソッドと HEAD メソッドは、検索以外のアクションを実行するという意味を持つべきではないという規則が確立されています。

リソースのブロックは、取得以外のアクションと見なされる場合があります。しかし、言葉遣いがそうするのを絶対に許してはなりません! 次のように言い換えることができます。推奨されませんが、有効です。ユーザーがその副作用を引き起こしていることさえ知らない場合は、さらに優れています。

当然のことながら、サーバーが GET 要求を実行した結果として副作用を生成しないことを保証することはできません。[..] ここでの重要な違いは、ユーザーが副作用を要求しなかったことです。

9.1.2 冪等メソッド

副作用のないシーケンスは、定義上、冪等です (ただし、同じリソース セットに対して同時操作が実行されていない場合)。

実装に伴う唯一の副作用は、同時リクエストのブロックです。シーケンシャル リクエストの副作用はありません。私は、9.1.2 が同時要求に対して副作用がないことは必須ではないという引用された一節を理解しています。だから、私から 9.1.2の有効なを取得します。

ところで。Retry-Afterヘッダーと一緒に503 Service Unavailableで答えます。

于 2014-01-19T06:50:56.893 に答える