javascript - soluciona - server error 404

En una aplicación de una sola página, ¿cuál es la forma correcta de tratar con URL incorrectas(errores 404)?

Question

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

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

Al mirar algunos sitios importantes, veo que gmail redireccionará a la bandeja de entrada si escribe una URL aleatoria debajo de https://mail.google.com/mail/ . Esto sucede en el lado del servidor (con un código http 300) o del lado del cliente, dependiendo de si la ruta incorrecta es anterior o posterior al carácter #. Por otro lado, Twitter muestra un HTTP 404 real para cualquier URL inválida. Una tercera opción sería mostrar un 404 "suave", una página de error puramente del lado del cliente.

Estas soluciones parecen apropiadas para diferentes situaciones. Twitter quiere que los enlaces a usuarios de Twitter y tweets sean enlaces reales, para que las personas puedan 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 a un tweet en mi sitio web, un simple rastreo me dirá eso). 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 URL sirve principalmente para el propósito de navegación del historial del navegador dentro del aplicación de una sola página. El tercer enfoque para dar errores suaves puede ser apropiado para situaciones similares a gmail, pero donde no hay una página razonable "predeterminada".

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 una aplicación de una sola página siempre debe redireccionar 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 redirigiendo a la bandeja de entrada, puede 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 probadas como gmail, ¿sería mejor mostrar una página de error?
• Para implementar 404 reales para aplicaciones de una sola página, parece necesario duplicar la lógica de enrutamiento en el lado del servidor. ¿Hay alguna forma de evitar esto?
• Al redireccionar 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 html5, creo que esto se puede lograr simplemente activando una recarga de la página actual (con la URL incorrecta), combinada con la ruta del servidor mencionada anteriormente. Para los navegadores que no son compatibles con esto o al usar la notación hashbang, esto no parece posible. ¿Cuál es la mejor manera de admitir todos los navegadores?

Answer 1

tl; dr: suelta el soporte hashbang y opta por el comportamiento similar a PJAX si te preocupa el SEO.

¿Estás haciendo una aplicación o un sitio web? Si el sitio web necesita devolver 404 para que no confunda Google. Debe ser un 404 real, no solo mostrar un mensaje de página no encontrado (es decir, 200 con el mensaje "página no encontrada" es muy malo). Además, ¿qué navegadores te importa apoyar?

Mi opinión es que se debe evitar toda la representación del lado del servidor hashbang (es decir, el desagradable Google SEO #! Hack). Utilice el estado real push o vuelva a procesar toda la página si la URL cambia para navegadores que no son compatibles con pushstate (no es un cambio de hash).

¡Ahora la razón por la que esto importa es que un #! nunca debería devolver un 404 porque no tiene sentido y es imposible imitar el lado del servidor porque el servidor nunca obtiene lo que está detrás del #! sin ejecutar Javascript.

Por lo tanto, si realmente te interesa el SEO, haré algo así como PJAX y solo usaré el verdadero pushstate para el enrutamiento y luego simplemente abandonaré el viejo web 1.0. En consecuencia, los enlaces que recomiendo que compartas, ¡que realmente pueden ser 404 , no deberían tener #! (el # tradicional está bien siempre que el contenido de la página no cambie drásticamente).

Finalmente, el 404 es en su mayoría un problema sino más bien un 30X es decir, respuestas de redireccionamiento. Eso es porque el navegador manejará automáticamente los redireccionamientos, por lo que sus llamadas Javascript AJAX nunca verán un 30X (en su lugar recibirán la respuesta de redireccionamiento ... es decir, 200). Para manejar las respuestas 30X , deberá enviar un encabezado para cada solicitud para indicar qué es / fue la URL redirigida (es decir, a qué fue redirigido) para no estropear el historial de Pushstate.

Por supuesto, si necesita apoyar hashbang como Twitter también ( y son los que incluso mataron a hashbang ), puede aprovechar Google Sitemaps y la función rel=nofollow para intentar mitigar el mal SEO.