http - 什么响应代码适合这种情况？

Question

我正在开发网页游戏。作为游戏的一部分，您从一组有限的功能开始，然后在玩游戏时解锁更多功能。

例如，您在教程的第 3 步中解锁了 /fields。但是，如果您只是导航到地址栏中的 /fields 呢？

我正在尝试找出响应的最佳状态代码。

403 看起来很理想，因为用户在解锁之前被禁止访问该页面。
404 也是有道理的，因为从技术上讲，该页面在解锁之前“不存在”，并且还会阻止用户区分不存在的页面和他们尚未解锁的页面。

但在这两种情况下，我都有一些用户报告浏览器缓存 403/404 结果的问题，并且即使在解锁后也不允许他们访问页面，除非他们完全清除缓存。

我想知道我是应该继续使用 403 还是 404，还是应该使用未使用的 4XX 代码，例如带有自定义状态文本的 442，或者甚至开玩笑地发送 HTTP/1.1 418 I'm A Teapot 以响应用户在他们不应该出现的地方四处张望。

我需要一个很好的、可靠的理由来说明为什么应该使用一个选项而不是其他选项。

Answer 1

tl;dr 409 Conflict将是一个想法，但也许你有缓存问题。在这种情况下，强制重新加载的缓存破坏器将起作用。

详细解释

也许是 409 Conflict状态码是有意义的:

10.4.10 409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

这是有道理的，因为资源只有在用户完成教程后才可用。在此之前，资源处于“无效”状态。并且用户可以通过完成教程来解决此冲突。

后来我进一步调查这个案子，发现细节决定成败。让我们阅读 403 Forbidden 的规范和 404 Not Found .

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

重要的是 «不应重复请求» 的规范。从不重新请求 403 页面的浏览器可能会做正确的事情。但是，让我们继续 404:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

[omitted]

现在我们有问题了!如果规范允许它们是临时的，为什么要缓存您的 404 页面？

也许在您的设置中，您的 403 和 404 页面的缓存配置不正确。如果是这样，请咨询this answer on StackOverflow .它给出了关于缓存 4xx 页面的详细答案。

如果您不想弄乱缓存 header ，请使用所谓的缓存破坏器并像这样传递系统时间(假设 PHP 是您的网络语言):

<a href="/fields?<?php echo time(); ?>">

这会生成类似 /fields?1361948122 的 URL , 每秒增加。这是 Markus A 提出的解决方案的变体。

我假设查询字符串 1361948122被您的资源忽略。如果不是，则改为在查询字符串参数中传递缓存破坏器，例如 t=1361948122并确保参数 t未由您的资源评估。