我正在开发一个网页游戏。作为游戏的一部分,您从一组有限的功能开始,然后在玩游戏时解锁更多的功能。
例如,在本教程的第3步中,您需要解锁/fields
。但是,如果您只浏览地址栏中的/fields
怎么办?
我正在尝试找出响应的最佳状态代码。
403似乎很理想,因为在用户解锁页面之前,禁止用户访问该页面。
404也是有道理的,因为页面在技术上“不存在”直到它被解锁为止,并且还阻止用户辨别不存在的页面和他们还没有解锁的页面之间的区别。
但是在这两种情况下,我都有一些用户报告浏览器缓存403/404结果的问题,并且即使解锁后也不允许他们访问该页面,除非他们完全清除了缓存。
我想知道我是否应该继续使用403或404,还是应该使用未使用的4XX代码(例如442)和自定义statusText,还是开玩笑地发送HTTP/1.1 418 I'm A Teapot
来响应用户在不应该出现的地方戳。
我需要一个充分而扎实的理由,为什么应该在其他选项上使用一种选项。
最佳答案
tl; dr 409 Conflict
是一个主意,但也许您在缓存方面遇到问题。在这种情况下,强制重新加载的缓存无效器将起作用。
详细说明
也许409 Conflict
状态码会有意义:
这将是有道理的,因为只有在用户完成本教程后该资源才可用。在此之前,资源处于“无效”状态。用户可以通过完成本教程来解决此冲突。
后来,我对该案件进行了更多调查,发现其中的细节是魔鬼。让我们阅读403 Forbidden
和404 Not Found
的规范。
重要的是“不应重复请求” 的规范。从不重新请求403页面的浏览器可能会做正确的事。但是,让我们继续404:
现在我们有问题了!如果规范允许它们是临时的,为什么还要缓存您的404页?
也许在您的设置中,您没有为403和404页面正确配置缓存。如果是这样,请咨询this answer on StackOverflow。它给出了有关缓存4xx页面的详细答案。
如果您不想弄乱缓存头,请使用所谓的缓存无效化器,并像这样传递系统时间(假设PHP为您的网络语言):<a href="/fields?<?php echo time(); ?>">
这样产生的URL类似于/fields?1361948122
,每秒增加一次。这是Markus A提出的解决方案的一种变体。
我假设查询字符串1361948122
被您的资源忽略。如果不是,请在querystring参数中传递cache-buster,例如t=1361948122
,并确保资源不对参数t
进行评估。
关于http - 哪种响应代码适合这种情况?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/14949495/