error-handling - 我可以在“404未找到文件”错误处理页面中包括哪些技术功能？

Question

我有一个自定义的404错误处理页面

它在数据库表中查找URL，如果有合适的目标，则重定向。将记录URL以及提供的重定向(如果有)，并且我们的应用程序具有管理报告以显示捕获了哪些URL，从而允许客户端设置更多等。

我们只有一个特定的Images文件夹，但是我们收到路径格式错误的图像请求。在/IMAGES/中可以找到匹配图像名称的地方，我们将其返回。我应该使用301吗？ (我们目前返回200)

我们会在“管理”报告中突出显示这些内容-因为可能是CMS或批量电子邮件或类似邮件中存在错误，并且通过重定向，我们只是掩盖了问题(解决该问题将有助于提高性能？)

我想知道当丢失的JPG/GIF/PNG出现404时是否应该返回虚拟图像？目前，我们返回的是404结果和HTML的抱歉页面-这让我有点傻，如果存在404响应代码，用户的浏览器会对返回的图像做任何有用的事情吗？

我还想知道返回一个图像“找不到图像，请访问www.example.com”是否有帮助(也许特别是如果我的域不是引荐来源!)。然后，无用的人错误地将我们的图片嵌入了他们的网站!可能至少会吸引我们一些流量。

同样，如果收到JS或CSS文件的404请求，是否应该返回有用的信息？至少在DEV中，我想知道我们已经犯了错误。有时，丢失的文件在使用上可能会非常模糊，以至于在质量检查中会丢失丢失的文件。 (我想有人 OUGHT 会在404日志中注意到它!)，但我在考虑将BODY设置为大型文件，或者返回.JS文件中的ALERT可能对DEV有帮助。

在今天的Google搜索中，我也忽略了以下建议:格式错误的查询字符串可以返回“400错误请求”和格式正确的查询字符串，但是其中参数具有无效值(例如，未找到产品代码)的处理方式为a404。如果我这样做并且还返回了内容(例如，说明页面)，用户是否会看到它，或者他们的浏览器可能将其替换为404错误的固定页面？ (我觉得早期版本的IE做到了吗？)

所有想法表示赞赏。

(在我的情况下是经典的ASP/IIS，但希望这个问题是通用的)

编辑:我还想知道是否有人对看起来像已知的黑客尝试的东西有什么特别之处？

http://www.example.com:80/admin/phpmyadmin/scripts/setup.php

http://www.example.com:80/admin/pma/scripts/setup.php

http://www.example.com:80/admin/scripts/setup.php

http://www.example.com:80/db/scripts/setup.php

http://www.example.com:80/dbadmin/scripts/setup.php

http://www.example.com:80/myadmin/scripts/setup.php

http://www.example.com:80/mysql/scripts/setup.php

http://www.example.com:80/mysqladmin/scripts/setup.php

http://www.example.com:80/phpadmin/scripts/setup.php

http://www.example.com:80/phpMyAdmin/scripts/setup.php

http://www.example.com:80/phpmyadmin1/scripts/setup.php

http://www.example.com:80/phpmyadmin2/scripts/setup.php

http://www.example.com:80/pma/scripts/setup.php

http://www.example.com:80/web/scripts/setup.php

和这些“感觉”:

http://www.example.com:80/_vti_bin/owssvr.dll？...

http://www.example.com:80/MSOffice/cltreq.asp？...

Edit2 :对不起，希望是事后的最后一次。

我应该分配一个 session ID吗？这将使我能够跟踪用户是否在第二次尝试时返回了更智能的信息(这可能导致我们向重定向表中添加条目)。创建 session 涉及在数据库和其他内容中创建 session 记录，因此不像发出404错误那样“便宜”

Answer 1

我曾经制作了一个网页，可以动态生成图像。问题是当无法渲染图像时如何传播错误。

我认为很好的解决方案是仅在图像本身中打印错误消息。然后，您可以对图像进行HREF，如果它不起作用，则会打印出错误消息。比仅返回无效图像更好。

对于JS文件，您可以执行相同的操作，但是我不知道这是否是一个好的设计。在这种情况下，我认为即使返回空文本文档也不是一件好事。您可以在警报框中返回错误消息，然后将其挂接到主应用程序中，但是我想这对于开发人员(而不是普通用户)更有用。 (取决于您的用户是谁)。我认为CSS也是如此。

对于一般的错误消息，如果您只想知道到达了无效的URL，则可以搜索服务器日志，也可以将脚本隐藏在JS/CSS URL后面，从而在某处记录了信息。

最后，请记住，HTTP代码是有原因的。您可以期望客户端比“伪造”和看起来不错的输出(从HTTP Angular 来看)更好地处理有效的HTTP错误代码。换句话说，您可以利用此优势，并在常规错误代码不足的情况下使用更具体的HTTP错误代码进行响应。