В настоящее время я пишу веб-приложение с использованием angularjs, но я думаю, что этот вопрос относится к любой клиентской платформе JavaScript, которая выполняет маршрутизацию на стороне клиента (как угловой).

В одностраничном приложении, как правильно обращаться с неправильными URL-адресами?

Просматривая несколько крупных сайтов, я вижу, что gmail будет перенаправлять на входящие, если вы введете любой случайный URL нижеhttps://mail.google.com/mail/, Это происходит на стороне сервера (с кодом http 300) или на стороне клиента, в зависимости от того, является ли неправильный путь до или после символа #. С другой стороны, твиттер показывает реальный HTTP 404 для любого неверного URL. Третий вариант - показать «мягкий» 404, чисто клиентскую страницу ошибок.

Эти решения кажутся подходящими для различных ситуаций. Твиттер хочет, чтобы ссылки для пользователей Твиттера и твиты были реальными ссылками, чтобы люди могли делиться ими, публиковать их в новостных статьях и т. Д., Поэтому важно, чтобы недопустимые ссылки распознавались как таковые (если у меня есть неработающая ссылка на твит в мой сайт, простое сканирование скажет мне, что). В gmail, с другой стороны, вы не должны делиться ссылками в своем почтовом ящике, и я даже не уверен, действительно ли ссылки постоянны / постоянны: кажется, что обновление URL в основном служит для навигации по истории браузера в одностраничное приложение. Третий подход предоставления мягких ошибок может быть подходящим для ситуаций, подобных gmail, но где нет разумной страницы по умолчанию.

После этого длинного вступления вот несколько конкретных вопросов:

Допустимо ли когда-либо выдавать «мягкую» страницу ошибки вместо ошибки 404, или одностраничное приложение всегда должно перенаправлять на реальный 404, если URL недействителен?Код Gmail может быть абсолютно безошибочным, но если в нем есть ошибка, приводящая к недействительным ссылкам, которые в конечном итоге перенаправляют обратно в папку «Входящие», это может быть еще более запутанным для пользователей, чем страница с ошибкой. Для большинства веб-приложений, которые не так хорошо протестированы, как gmail, было бы лучше показать страницу с ошибкой?Для реализации реальных 404-х для одностраничных приложений кажется необходимым дублировать логику маршрутизации на стороне сервера. Есть ли способ обойти это?Я думаю, что при перенаправлении на 404 пользователь должен видеть URL-адрес, вызвавший ошибку, возможно, в строке URL-адреса. Я думаю, что с помощью API истории html5 это можно сделать, просто вызвав перезагрузку текущей страницы (с неверным URL) в сочетании с упомянутой выше маршрутизацией на стороне сервера. Для браузеров, которые не поддерживают это или при использовании нотации hashbang, это кажется невозможным. Каков наилучший способ поддержки всех браузеров?