在单页应用程序中，处理错误URL(404错误)的正确方法是什么?

我目前正在使用angularjs编写Web应用程序，但是我认为这个问题适用于在客户端进行路由的任何客户端javascript框架(

I am currently writing a web application using angularjs, but I think this question applies to any client-side javascript framework that does routing on the client side (as angular does).

在单页应用程序中，处理错误URL的正确方法是什么?

In a single-page app, what is the right way to deal with wrong URLs?

查看一些主要网站，我发现，如果您在 https://mail下输入任意随机网址，gmail将会重定向到收件箱.google.com/mail/.这发生在服务器端(带有http 300代码)或客户端，具体取决于错误的路径是在#字符之前还是之后.另一方面，twitter显示任何无效URL的真实HTTP 404.第三种选择是显示软" 404，即纯客户端错误页面.

Looking at a few major sites, I see that gmail will redirect to the inbox if you type any random URL below https://mail.google.com/mail/. This happens server-side (with an http 300 code) or client-side, depending on whether the wrong path is before or after the # character. On the other hand, twitter shows a real HTTP 404 for any invalid URL. A third option would be to show a "soft" 404, a purely client-side error page.

这些解决方案似乎适用于不同情况. Twitter希望将指向Twitter用户和Tweet的链接作为真实链接，以便人们可以共享它们，将其发布在新闻文章中，等等，因此，必须将无效链接识别为这样的链接(如果我对Tweet的断开链接很重要)，这一点很重要.我的网站，简单的抓取就会告诉我).另一方面，在gmail中，您不希望将链接共享到收件箱中，而且我什至不确定链接是否真的是永久性的/持久性的:似乎url更新主要用于在浏览器中进行历史记录导航单页应用程序.给出软错误的第三种方法可能适用于类似于gmail的情况，但是没有合理的默认"页面.

These solutions seem appropriate for different situations. Twitter wants the links to twitter users and tweets to be real links, so people can share them, post them in news articles, etc, so it is important that invalid links be recognized as such (if I have a broken link to a tweet in my website, a simple crawl will tell me that). In gmail, on the other hand, you are not expected to share links into your inbox, and I'm not even sure if the links are really permanent/persistent: it seems the url updating mostly serves the purpose of browser history navigation within the single-page app. The third approach of giving soft errors might be appropriate for situations similar to gmail, but where there is no reasonable "default" page.

在进行了漫长的介绍之后，这里有一些具体问题:

After this long introduction, here are some specific questions:

• 提供软"错误页面而不是404错误是否可以接受，或者如果URL无效，单页应用程序应该始终重定向到真实的404吗?
• Gmail的代码可能完全没有错误，但是，如果确实存在导致导致无效链接的错误，该链接最终会重定向回收件箱，则与错误页面相比，对于用户而言，这甚至可能更加令人困惑.对于大多数没有经过gmail测试的Web应用程序，显示错误页面会更好吗?
• 要为单页应用程序实现真正的404，似乎有必要在服务器端复制路由逻辑.有什么办法解决吗?
• 重定向到404时，我认为用户应该能够在URL栏中看到导致错误的URL.我认为使用html5历史记录api，只需触发当前页面的重新加载(使用错误的url)，再结合上面提到的服务器端路由，就可以实现.对于不支持此功能的浏览器或使用hashbang表示法，这似乎是不可能的.支持所有浏览器的最佳方法是什么?