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

Question

我正在开发一个网络游戏.作为游戏的一部分,您可以从一组有限的功能开始,并在游戏时解锁更多功能.

例如,您/fields在本教程的第3步中解锁.但是,如果你只是导航到/fields地址栏呢？

我正在尝试找出最好的状态代码来回应.

403似乎是理想的,因为禁止用户在解锁之前访问该页面.
404也有意义,因为页面在技术上"不存在"直到它被解锁并且还阻止用户能够区分不存在的页面和它们尚未解锁的页面之间的区别.

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

我想知道我是否应该继续使用403或404,或者我是否应该使用未使用的4XX代码(例如带有自定义statusText的442),或者甚至是开玩笑地发送HTTP/1.1 418 I'm A Teapot以响应用户在不应该的地方进行搜索.

我需要一个好的,坚实的理由,为什么应该使用一个选项而不是其他选项.

Answer 1

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

长解释

也许409 Conflict状态代码会有意义：

10.4.10 409 冲突

由于与资源的当前状态冲突，无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应主体应该包含足够的信息让用户识别冲突的来源。理想情况下，响应实体应包含足够的信息供用户或用户代理解决问题；然而，这可能是不可能的，也不是必需的。

响应 PUT 请求时最有可能发生冲突。例如，如果正在使用版本控制并且被 PUT 的实体包含对资源的更改，该更改与先前（第三方）请求所做的更改发生冲突，则服务器可能会使用 409 响应来指示它无法完成请求. 在这种情况下，响应实体可能会以响应 Content-Type 定义的格式包含两个版本之间差异的列表。

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

后来我稍微调查了这个案子，我发现魔鬼在细节中。让我们阅读的规范403 Forbidden和404 Not Found。

10.4.4 403 禁止

服务器理解请求，但拒绝满足它。授权无济于事，不应重复该请求。如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，它应该在实体中描述拒绝的原因。当服务器不想透露请求被拒绝的确切原因时，或者当没有其他响应适用时，通常使用此状态代码。

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

10.4.5 404 未找到

服务器未找到任何与请求 URI 匹配的内容。没有说明这种情况是暂时的还是永久性的。

[省略]

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

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

如果您不想弄乱缓存标头，请使用所谓的缓存破坏器并像这样传递系统时间（假设 PHP 作为您的网络语言）：

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

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

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