禁止某些并发 GET 请求是否违反 RFC 2616（安全/幂等性）？答案

【问题标题】：Does disallowing some concurrent GET requests violate RFC 2616 (safety/idempotency)?禁止某些并发 GET 请求是否违反 RFC 2616（安全/幂等性）？
【发布时间】：2013-02-26 14:42:07
【问题描述】：

我目前正在讨论关于在给定资源上禁止并发 GET 请求是否构成违反 RFC 2616 的问题（尤其是 GET 方法所需的幂等性和安全属性，第 9.1 节）。

例如；如果我的服务器收到一个获取 /data/?dataId=123456 同时两次，您认为一个或两个请求返回错误消息是违反安全性还是幂等性？

根据我的理解，RFC 规定相同的请求在再次调用时应该产生相同的结果。然而，我还没有看到任何关于并发请求的行为是可以接受的。

我的感觉是，禁止并发 GET 访问（在给定资源上，当然不是一般规则）并不构成违反 RFC。返回 423 响应代码，或 500（虽然不是很优雅），甚至是 429 或 420（尽管含义略有不同）似乎对我来说是可以接受的。

我想知道是否有有效的论据证明 RFC 否认这一立场。

提前致谢/致以最诚挚的问候

【问题讨论】：

文件共享服务每天都会执行此操作 - 一次下载一次，甚至每个 URL 仅下载一次。稍后使用的相同 URL 会产生截然不同的结果。
423 不正确。 420 未定义。您可以使用 429，但我不完全了解您的用例。你为什么想要阻止请求？？？？
（你说得对 423）这个问题主要是反问的，但用例是针对需要访问不支持并发访问的资源的 GET 请求。我绝对可以将请求排队，直到资源被释放，但我想知道 RFC 合规性以防我决定不这样做，并且只返回一个错误代码（这是我们目前所做的，因为在我们的情况下并发访问通常不会发生）
（420是twitter API用来限制查询速率的响应码）

标签： http concurrency get rfc2616

【解决方案1】：

9.1.1 Safe Methods

特别是，已经确立了 GET 和 HEAD 方法不应该具有采取除检索之外的操作的意义的约定。

阻止资源可能符合检索以外的操作。但是SHOULD NOT 的措辞绝对允许您这样做！您可以将其改写为：不推荐，但有效。如果用户甚至不知道他正在造成这种副作用，那就更好了：

当然，无法确保服务器不会因为执行 GET 请求而产生副作用； [..] 这里的重要区别是用户没有请求副作用。

9.1.2 Idempotent Methods

根据定义，从不产生副作用的序列是幂等的（前提是没有并发操作在同一组资源上执行）。

您的实现的唯一副作用是阻止并发请求。顺序请求没有副作用。我理解引用的段落不需要 9.1.2 对并发请求没有副作用。所以你从我这里得到了 9.1.2 的有效。

顺便说一句。我会用503 Service Unavailable 和Retry-After 标题来回答。

【讨论】：

【解决方案2】：

在操作上，您的服务器可以在保护其资源免受攻击方面为所欲为。

也就是说，禁止对资源的任何个并发 GET 会让许多客户感到惊讶，委婉地说。

【讨论】：