为什么 Django 不使用默认的 404 视图传递错误消息？答案

【问题标题】：Why does Django not pass on error messages with the default 404 view?为什么 Django 不使用默认的 404 视图传递错误消息？
【发布时间】：2011-12-08 16:44:25
【问题描述】：

（背景：我对 Django 和 Web 开发还是很陌生。）

1) 有人可以解释以下陈述的原因吗？ This Q/A 回答了如何处理它的问题，但没有回答为什么它可能是好的/坏主意。

The docs state, "page_not_found 视图应该足以满足 99% 的 Web 应用程序，但如果你想覆盖它，你可以在你的 URLconf 中指定 handler404”。

即page_not_found视图只传递请求的URL而忽略您在引发异常时提供的任何消息。在我看来，这具有选项为 404.html 模板提供有用的提示默认情况下对每个人都有好处。

2) 我目前正在制作自定义视图，以便在以下情况下传递有用的消息。有什么理由我不应该这样做吗？

我正在使用矩阵 URL，因此基本资源是一个普通的分层 URL，后跟基本的矩阵选项格式： ;filter_type1=item:value,item:value;filter_type2=item:value...

因此很容易根据进展情况提供有用的信息解析在出现错误之前得到。通过似乎对我有帮助在如下消息上：

“允许的过滤器类型为：type1、type2、type3。”或
“filter_type a 允许的项目是：item1、item2、item3。”

如果我在其他地方错过了这个解释，我们深表歉意。我查看了asked on google django-users，但没有得到回复。

【问题讨论】：

感觉这个问题只是间接回答了。但是根据目前的答案，我必须假设答案是：如果您需要 404 中的错误消息，那么您做错了。

标签： django

【解决方案1】：

我不太确定问题是什么。默认情况下，page_not_found 视图是基本视图，因为在很多情况下，您需要解释为什么找不到该页面，除非它没有。

我认为“矩阵选项”是指 URL/GET 参数，例如：

http://domain.com/page/?option1=value&option2=value..

如果他们输入了错误的参数组合而不是抛出 404，为什么不默认为基本 url/模板 (http://domain.com/page/) 并显示错误消息“Option1 只能是 x， y,z”。通过这种方式，他们会看到熟悉的页面，并且可以重试他们的选择，而无需从 404 页面返回（而且不会让人感到困惑，为什么它不起作用）。

您可以使用 django 的 messaging framework 轻松完成此操作（我过去曾这样做过）。检查视图中的参数时，将错误消息传递给模板。

【讨论】：

"...默认情况下是基本的，因为您需要解释为什么找不到页面的情况并不多..." 我只看到过诸如您的断言和文档表明该消息的情况并不多。我完全可以接受这也许是真的，但我寻找的不仅仅是断言。您对第二部分的解释通过说显示错误消息可能不是“错误”，但可能有更好的方法来帮助我。感谢您的回答！
找不到页面的原因你能想到什么。 (1) 链接被破坏，(2) 用户输入错误（参见#1）。如果有其他原因，例如输入了无效数据，则不应是 404。使用其他 HTTP 响应代码表明响应失败。 409：数据冲突，403：禁止等
很公平。我自己也想过这个问题。与我对 Matthew 的评论类似，假设 URL 中的过滤器/订单参数格式不正确。不是404吗？也许我在叫错树。我确实查看了所有 HTTP 响应，但没有找到更合适的响应。
我会返回 409：冲突。（或普通的 400：错误）。但是，如果您只是呈现 HTML，那么您将返回 200，但页面数据显示存在错误。（我的大部分网络应用程序编程都是基于 API 的，其中 4xx 系列响应可以而且确实有一个主体。）

【解决方案2】：

如果你的数据是这样的：

http://example.com/foo;bar;baz

那你做错了:)

然后您需要使用正则表达式来解析要处理的数据。

有些人在遇到问题时会想“我知道，我会用正则表达式。”现在他们有两个问题。

（扎温斯基，1997 年）

相反，正如 pastelegs 所建议的，使用 GET 参数。

更好的是，利用 django 表单处理和：

创建一个具有验证规则的表单
从该表单呈现输入页面
使用表单解析用户输入
如果表单有效则显示数据，否则在用户输入旁边显示验证错误

您可以使用 GET 请求或 POST 请求来执行此操作。 POST 具有“干净”的 url 和更长的数据主体的优势。 GET 表示可以为 url 添加书签。

这一切归结为使用框架的正确部分来完成正确的任务。 URL 路由使用正则表达式来计算出哪个 URL 命中了哪个视图。您制作的 url 模式越简单，它们就越容易维护。用户输入应由表单处理。

【讨论】：

关于“做错事”的观点。只是为了解释一下……在阅读了 Tim Berners-Lee 的 RESTful web development 和 Matrix URIs (1996) 之后，我受到启发，编写了一个用于处理分号格式的矩阵 URI 的系统。这是一个比查询更灵活的系统，但它只是没有在框架中实现，所以是的，它需要解析:)
参数内容本身并不是用户输入。它们是将出现在页面上的数据列表的过滤器和排序方向。如果提供了一些控件，它们可以由用户修改。所以在这种情况下，假设我转换为使用查询字符串和 GET 参数，正确的方法是什么？查询字符串中的过滤器/顺序参数格式错误？
我的立场是，如果用户选择了东西，然后这会影响传入的数据，那就是用户输入。它可能在某种程度上由应用程序的客户端验证，但仍应由服务器验证。至于排序：如果您使用映射（并使用表单，您将使用），那么它就消失了。数据不正确：-> 重新呈现显示数据如何冲突的表单。
为了更清楚：不要执着于表单通常是 HTML 字段这一事实。如果可以的话，让您的页面控件更新
元素中的隐藏字段，然后将其发布。

【解决方案3】：

我认为您无法理解这一点的原因是，您试图混合 2 个不同的问题。

首先，是否找到实际页面的问题。
其次是提供的参数是否有效的问题。

所以，如果（部分）url 是：

    .../whatever/?param1=value1&param2=value2

如果页面/whatever/default找不到，您将（应该）看到"404 Page not found" 类型的错误消息。在这种情况下，您无法判断所提供的参数或值是否正确。请求的页面不存在，因此您不知道参数用于哪个页面。您甚至不能假设指定了正确的domain name。可能有许多参数有效的任意域、url 和页面，以及许多其他参数无效的域、url 和页面。

如果页面/whatever/default找到，那么：
如果指定错误的参数可能会导致该页面加载/重定向一个不存在的页面，那么该页面应该阻止这种情况。如有必要，应该由该页面来验证所提供的参数，并采取适当的行动并显示适当的消息。

【讨论】：