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

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

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

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

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

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

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

Ответ 1

tl; dr: Оставьте поддержку hashbang и выберите PJAX, как если бы вы заботились о SEO.

Вы создаете приложение или веб-сайт? Если веб-сайт вам нужно вернуть 404, чтобы вы не путали Google. Он должен быть реальным 404, а не просто показывать сообщение страницы не найденное (т.е. 200 с сообщением "страница не найдена" очень плохо). Также, какие браузеры вы хотите поддержать?

Мое мнение состоит в том, что следует избегать всего рендеринга на стороне сервера hashbang (т.е. неприятного взлома Google SEO #!). Либо используйте реальную pushstate, либо повторно отрисуйте всю страницу, если URL-адрес изменится для браузеров, которые не поддерживают pushstate (не изменение хэша).

Теперь причина в том, что #! никогда не должен возвращать 404, потому что это не имеет смысла и его невозможно подражать стороне сервера, потому что сервер никогда не получает то, что после #!, с запущенным Javascript.

Таким образом, если вы действительно заботитесь о SEO, я бы сделал что-то вроде PJAX и использовал только истинную pushstate для маршрутизации, а затем просто не смог использовать старую версию 1.0. Следовательно, ссылки, которые я рекомендую вам поделиться, которые действительно могут быть 404, не должны иметь #! (традиционный # быть точным, если содержимое страницы не изменяется резко).

Наконец, 404 в основном не проблема, а скорее 30X, то есть перенаправление ответов. Это потому, что браузер автоматически обрабатывает перенаправления, поэтому ваши вызовы Javascript AJAX никогда не будут видеть 30X (вместо этого они получат ответ перенаправления... т.е. 200). Чтобы обрабатывать ответы 30X, вам нужно будет отправить заголовок для каждого запроса, чтобы указать, на что был перенаправлен URL-адрес (т.е. На что вы перенаправлены), чтобы вы не испортили историю Pushstate.

Конечно, если вам нужно поддерживать хешбанг, как и Twitter (и это те, которые даже убили хэш-бэнг), вы можете использовать Google Sitemaps и rel=nofollow, чтобы попытаться смягчить плохой SEO.