Atualmente estou escrevendo um aplicativo da web usando angularjs, mas acho que esta questão se aplica a qualquer estrutura de javascript do lado do cliente que faz o roteamento no lado do cliente (como angular).

Em um aplicativo de uma única página, qual é o caminho certo para lidar com URLs incorretos?

Olhando para alguns sites importantes, vejo que o Gmail irá redirecionar para a caixa de entrada se você digitar qualquer URL aleatória abaixohttps://mail.google.com/mail/. Isso acontece no lado do servidor (com um código HTTP 300) ou no lado do cliente, dependendo se o caminho errado está antes ou depois do caractere #. Por outro lado, o twitter mostra um verdadeiro HTTP 404 para qualquer URL inválido. Uma terceira opção seria mostrar um "soft" 404, uma página de erro do lado do cliente.

Essas soluções parecem apropriadas para diferentes situações. O Twitter quer que os links para usuários do Twitter e tweets sejam links reais, para que as pessoas possam compartilhá-los, publicá-los em artigos de notícias, etc., por isso é importante que links inválidos sejam reconhecidos como tal (se eu tiver um link quebrado para um tweet em meu site, um simples rastreamento vai me dizer isso). No gmail, por outro lado, não é esperado que você compartilhe links na sua caixa de entrada, e eu nem tenho certeza se os links são realmente permanentes / persistentes: parece que a atualização de URLs serve principalmente ao propósito de navegação do histórico do navegador dentro do aplicativo de uma única página. A terceira abordagem de fornecer erros de software pode ser apropriada para situações semelhantes ao gmail, mas onde não há uma página "padrão" razoável.

Depois dessa longa introdução, aqui estão algumas perguntas específicas:

É sempre aceitável dar uma página de erro "soft" em vez de um erro 404, ou um aplicativo de página única sempre deve redirecionar para um 404 real se um URL for inválido?O código do Gmail pode ser perfeitamente livre de erros, mas se ele tiver um bug que leve a links inválidos que acabam redirecionando para a caixa de entrada, isso pode ser ainda mais confuso para os usuários do que uma página de erro. Para a maioria dos aplicativos da web disponíveis, que não são tão bem testados quanto o Gmail, seria melhor mostrar uma página de erro?Para implementar 404s reais em aplicativos de página única, parece necessário duplicar a lógica de roteamento no lado do servidor. Existe alguma maneira de contornar isso?Ao redirecionar para um 404, acho que o usuário deve conseguir ver o URL que causou o erro, possivelmente na barra de URL. Com a api de histórico html5, acho que isso pode ser feito simplesmente acionando um recarregamento da página atual (com o URL incorreto), combinado com o roteamento do lado do servidor mencionado acima. Para navegadores que não suportam isso ou quando usam notação de hashbang, isso não parece possível. Qual é a melhor maneira de suportar todos os navegadores?