Actualmente estoy escribiendo una aplicación web usando angularjs, pero creo que esta pregunta se aplica a cualquier marco de javascript del lado del cliente que realiza enrutamiento en el lado del cliente (como lo hace angular).

En una aplicación de una sola página, ¿cuál es la forma correcta de lidiar con las URL incorrectas?

Si observo algunos sitios importantes, veo que gmail se redirigirá a la bandeja de entrada si escribe alguna URL aleatoria a continuación.https://mail.google.com/mail/. Esto sucede en el lado del servidor (con un código http 300) o en el lado del cliente, dependiendo de si la ruta incorrecta es antes o después del carácter #. Por otro lado, Twitter muestra un HTTP 404 real para cualquier URL no válida. Una tercera opción sería mostrar un 404 "blando", una página de error puramente del lado del cliente.

Estas soluciones parecen apropiadas para diferentes situaciones. Twitter quiere que los enlaces a los usuarios de Twitter y los tweets sean enlaces reales, para que la gente pueda compartirlos, publicarlos en artículos de noticias, etc., por lo que es importante que los enlaces no válidos sean reconocidos como tales (si tengo un enlace roto en un tweet en Mi sitio web, un simple rastreo me dirá que). En Gmail, por otro lado, no se espera que compartas enlaces en tu bandeja de entrada, y ni siquiera estoy seguro de si los enlaces son realmente permanentes / persistentes: parece que la actualización de la URL sirve principalmente para la navegación del historial del navegador dentro del aplicación de una sola página. El tercer enfoque de dar errores blandos puede ser apropiado para situaciones similares a gmail, pero donde no hay una página "predeterminada" razonable.

Después de esta larga introducción, aquí hay algunas preguntas específicas:

¿Es aceptable dar una página de error "suave" en lugar de un error 404, o debería una aplicación de una sola página redirigir siempre a un 404 real si una URL no es válida?El código de Gmail puede estar perfectamente libre de errores, pero si tiene un error que conduce a enlaces no válidos que terminan redirigiéndose nuevamente a la bandeja de entrada, eso podría ser aún más confuso para los usuarios que una página de error. Para la mayoría de las aplicaciones web, que no están tan bien probadas como Gmail, ¿sería mejor mostrar una página de error?Para implementar los 404 reales para aplicaciones de una sola página, parece necesario duplicar la lógica de enrutamiento en el lado del servidor. ¿Hay alguna manera de evitar esto?Al redirigir a un 404, creo que el usuario debería poder ver la URL que causó el error, posiblemente en la barra de URL. Con la API de historial de html5, creo que esto se puede lograr simplemente activando una recarga de la página actual (con la URL incorrecta), combinada con el enrutamiento del lado del servidor mencionado anteriormente. Para los navegadores que no admiten esto o cuando se usa la notación hashbang, esto no parece posible. ¿Cuál es la mejor manera de soportar todos los navegadores?