“EULA 未接受”的 HTTP 状态代码？答案

【问题标题】：HTTP status code for "EULA not accepted"?“EULA 未接受”的 HTTP 状态代码？
【发布时间】：2016-04-15 17:08:30
【问题描述】：

我有一个 RESTful Web 服务，它需要接受最终用户许可协议 (EULA) 才能使用。

如果 EULA（尚未）被接受，哪个 HTTP 状态代码最适合 Web 服务返回？

目前我看到以下可能性（我目前最喜欢的粗体字）：

403 禁止
412 前置条件失败
417 预期失败
423 锁定
需要428个前置条件#
451 因法律原因不可用

【问题讨论】：

所以，随便选一个。你有什么问题？ :) 要选择“最合适”的状态代码，您可以列出您可以发送它们的所有条件，并交叉任何要求与您的方案不匹配的列表。
我看到有几票接近。显然，这被认为是一个让我感到惊讶的意见驱动问题——这真的只是我个人的品味吗？在所有 HTTP 状态代码都标准化之后，如果我选择例如是否可以？ 404 表示 EULA 问题，即使每个人看到该状态代码都会立即认为请求的资源不存在？
问题不是基于观点的，而是如目前所说，它吸引的是基于观点的答案，而不是基于事实的答案。这是关于“对于任意情况 X 使用哪个 HTTP 状态代码” 的问题所固有的，因为人们不会费心阅读 RFC。您应该能够做到这一点，正如我在之前的评论中指出的那样。列出候选代码并消除任何与您的情况不匹配的代码。
我也喜欢 451，谢谢，这是我最喜欢的 http 状态码 :) 但是，我认为 403 更合适。根据 RFC 7725 The use of the 451 status code implies neither the existence nor nonexistence of the resource named in the request. That is to say, it is possible that if the legal demands were removed, a request for the resource still might not succeed. tools.ietf.org/html/rfc7725 换句话说，它更像是一个 404 “这不存在”，而您真正想说的是“它在那里，但我不会让你看到它”。

标签： rest http http-status-codes

【解决方案1】：

按照CodeCaster 的建议，我去了w3.org 并查看了definitions of HTTP Status Codes in RFC2616。我发现状态码 403 最合适：

10.4.4 403 禁止

服务器理解请求，但拒绝执行。授权将无济于事，并且不应重复请求。如果请求方法不是 HEAD 并且服务器希望公开为什么请求没有被满足，它应该描述原因对于实体的拒绝。如果服务器不想让此信息可供客户端使用，状态码 404（不 Found) 可以代替。

【讨论】：

【解决方案2】：

消息应该是不言自明的，我也投票支持 412 Precondition Failed。

【讨论】：

但这不是 HTTP 状态代码的工作方式。请阅读When is it appropriate to respond with a HTTP 412 error?。对于失败的条件请求，将返回 412。

【解决方案3】：

401 未经授权

正如乔治克鲁尼所说：“还有什么！”。在人们同意 EULA 后，您授权他们访问您的服务。他们没有这样做，所以他们没有被授权（为了符合 RFC，验证和重试客户端必须包含 WWW-Authenticate 标头，但您必须以某种方式无论如何都要提供该信息，这种方式与其他任何方式一样好）。

换一种思路，您也可以返回 301 指向协议页面。这种方法背后的原因是 4xx 代码表示错误情况。但是，尚未同意 EULA（除了失败身份验证）并不是真正的错误情况。
它阻止了服务被使用，是的......但一切都“工作正常”。

【讨论】：

这个问题与认证无关。您在谈论的是身份验证，这不是 401 的用途。见403 Forbidden vs 401 Unauthorized HTTP responses。
第二个“认证”当然应该是“授权”。
@CodeCaster：不，不应该。您链接的 Q 中接受的答案完全证实了我的推理。代码的含义是服务器收到了一个完整的、有效的请求，但它没有收到一个身份验证令牌（因此你的困惑！）授权你访问资源。这可能是因为您的令牌无效或属于错误的组或其他原因，或者仅仅是因为您根本没有提供令牌。现在，这就是这里正在发生的事情。您必须同意 EULA，并收到一个令牌，证明您是“已接受 EULA”用户组的成员。
... 反过来，它会授权您（如果您提供令牌）。所以，授权是正确的词。 403 Forbidden 是错误的。访问资源并没有被禁止（不是一般情况下，也不是特别针对您），只是不清楚您是可以访问它的人。您没有通过所需的检查，仅此而已。
好吧，我猜 OP 的 API 用户会一次性 POST 到 AcceptEula 以将他们的帐户标记为“可以使用 API”，而不是 OP 引入了新的基于 EULA 和令牌的身份验证方案。因此，这个问题与 authorization 有关，这不是 401 的用途。 401 响应必须包含 WWW-Authenticate 响应标头，除非 OP 发明了自己的模式，否则无法完成。我没有在任何地方提倡 403，但如果你真的 read the RFC，你会发现在这种情况下这将是一个可行的回应。