Настройка любого CDN для доставки только одного файла независимо от того, какой URL был запрошен

В настоящее время я работаю над новым проектом, в котором вся страница должна быть реализована в HTML5/JS, работающей против API/JSON. Поскольку все приложение должно состоять только из одного HTML файла (index.html) и приложения JS MVC (возможно, backboneJs), я думаю о SEO и дружественных к пользователю URL-адресах.

Там я наткнулся

window.document.pushstate('','title','/url');

С помощью этой функции html5 я могу определить URL-адреса, не покидая или перезагружая страницу. НО... Я хочу развернуть приложение в CDN, например Amazon CloudFount по причине производительности и низкой стоимости. Мне не нужна инфраструктура сервера (помимо того, что мне нужно для API, конечно)

Итак, я могу настроить CDN (на самом деле любой CDN, такой как AWS, Azure, Akamai), чтобы предоставить один и тот же файл HTML независимо от того, какой URL-адрес вызывается

http://www.example.com = > поставляет index.html

http://www.example.com/any_subpage = > поставляет index.html

и т.д.

рабочий пример можно найти в http://html5.gingerhost.com. Но создатель этой страницы может использовать файл .htaccess или что-то знакомое, чтобы отобразить все в один и тот же файл. Я хочу предоставить такую ​​же функциональность в CDN.

ОТВЕТЫ

Ответ 1

Любой CDN должен иметь возможность определять исходный сервер. С этим сервером связывается CDN, чтобы обслуживать файл, если его местоположение отсутствует.

Хорошей новостью является то, что исходным сервером может быть все, что обслуживает веб-страницы, такие как Apache, Nginx и т.д. Это означает, что вы можете применять любые правила перезаписи, которые вы пожелаете.

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

Ответ 2

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

Я не думаю, что это действительно способный агностик. Вы всегда будете привязаны либо к серверной технологии, либо к платформе балансировки нагрузки/брандмауэра. Но похоже, что у вас уже есть это ограничение, поскольку вам нужно где-то разместить свой JSON API? Даже если вы еще не определились на платформе, практически любая платформа должна позволить вам выполнить базовую маршрутизацию. Если вы можете подавать запросы JSON Http, вы также сможете выполнять маршрутизацию страниц.

Как замечание, я не верю, что вы хотите вернуть свой "index.html" из абсолютно всех возможных URL-адресов в вашем домене. Вам понадобится список допустимых URL-адресов и недопустимых URL-адресов. В этом случае вам нужно будет проверять ваш задний конец, чтобы проверить URL-адрес запроса. Это еще раз говорит мне о том, что технология на стороне сервера будет лучше подходит для этой задачи, а затем слепой "перехват" перенаправления на более низком уровне.

Мои личные предпочтения состоят в том, чтобы использовать вашу любимую среду MVC для работы с индексируемым контентом с требуемой структурой URL (почти все загрузки страниц), а затем использовать JSON api для работы с этим контентом после загрузки страницы (любой динамический материал, который вы хотите быть в состоянии сделать). Все это, как загрузки страниц, так и API, обслуживается с той же серверной платформы/среды.

Ответ 3

Symlink ваша страница 404 на индексную страницу. Таким образом, если запрашиваемый URL-адрес не найден на вашем веб-контенте (о какой-либо ссылке, как показано в вашем случае), страница 404 обслуживается, что в свою очередь является самой страницей индекса.

# ln -s index.html 404.html

Ответ 4

Сервер HTTP Nginx может сделать это как:

location /{
    # serve a file
}

или вы можете настроить свои ссылки, например

location /my_html{
     # serve html file
}

location /cdn/{
     # serve rest files
}

вы даже можете проверять URL-адреса с помощью регулярных выражений

location ~ /cdn/.*\.js${
    # serve cdn
}

Ответ 5

Недавно мы связались с edgecast.com (который является облачным флагом cdn), и благодаря их поддержке они сказали мне, что это действительно то, что они может, но не через стандартный интерфейс. Мне сказали просто связаться с ними, когда нам нужен шаблон подстановочного знака для одного файла.

Что касается вашего вопроса: да, это возможно. Просто свяжитесь с ними через их чат, и они помогут вам, удачи!

Дополнительная (отрицательная) информация: Подобное catch-all-rule означает, что глупый favicon.ico-принудительный запрос некоторых браузеров (read IE) будет пойман, а регулярная html-страница будет загружена снова. Фактически, все автоматические запросы (iframe также запрашивают favicon, например) против корневого домена будут пойманы, и будет загружен обычный html файл. Это может быть или не быть проблемой для вас, но для меня все эти скрытые запросы заставляют меня переосмыслить решение и использовать веб-сервер для того, чтобы сделать фактический улов. Позор действительно.

Ответ 6

Если у вас есть собственный домен, указывающий на CDN (я знаю, что CloudFront позволяет это сделать), вы можете использовать CloudFlare (https://www.cloudflare.com/) в качестве обратного прокси-сервера между вашими пользователями и CDN.

Благодаря своему свободному плану вы можете создать правило, которое перенаправляет все на index.html. Я думаю, что это единственный способ добиться того, чего вы хотите, учитывая, что CDN настроены на обслуживание только статических существующих файлов, как вы знаете.

Ответ 7

Если вы рассматриваете SEO и дружественные URL-адреса, вы можете выполнить некоторые из них, используя pushState, конечно. Просто помните, что:

  • При перенаправлении всех маршрутов в index.html вы также будете обслуживать то же самое содержимое html в поисковых системах, независимо от того, на каком URL они идут. Тогда не имеет значения, как "SEO-friendly" ваш URL-адрес.

  • Если вы считаете поддержку IE, она не поддерживает API истории, поэтому вам понадобится структура истории более высокого уровня или какой-либо другой обходной путь для IE. И это, скорее всего, включает URL-адреса, основанные на #. Таким образом, у вас будет в основном два разных URL для каждого представления, это то, что нужно учитывать, когда люди обмениваются URL-адресами или выясняют, как поисковые роботы ловит ссылки на ваш сайт.

Я бы предложил рассмотреть следующие два варианта, прежде чем заходить слишком далеко в поисках подходящего облачного узла:

  • Отключить некоторую логику данных на бэкэнд и обслуживать по крайней мере некоторое усваиваемое содержимое для каждого представления. Вы по-прежнему можете удалить или, возможно, проанализировать этот контент в своем приложении и сделать свою работу pushstate/jsonAPI для лучшего UX, но у вас будут "истинные", проверенные URL-адреса для поисковых систем, пользователей мини-игр и некоторых других неудачных браузеров. Эти статические страницы не должны обслуживать одни и те же функциональные возможности или даже стили, просто подумайте об этом как о последнем спаде.

  • Забудьте о CDN для приложения, просто используйте CDN для статических файлов, изображений, скриптов и т.д. У вас может быть пара резервных копий для самого приложения, но его носитель, который действительно тянет сервер. Это позволит вам контролировать приложение и сервер, находящиеся за ним, но вы все равно можете использовать CDN для того, что он предназначен для обслуживания статического контента.

Ответ 8

Я нахожусь в той же лодке, что и вы, и кажется, что cdn не поддерживает переписывание URL. Следующее решение не решит нашу "проблему" точно, но приблизится к экономии $для хостинга, если вы используете провайдер CDN "pull".

Первоначальная загрузка страницы по умолчанию (index.html) предоставит только крошечный фрагмент html, в основном, html-структуру bare-bones, например:

<!doctype html>
<html lang="en">
<head>
    <title>something</title>
    <!-- Load the script "js/main.js" as our entry point -->
    <script data-main="js/main" src="http://mycdn.com/js/libs/require/require.js"></script>
</head>
<body>

</body>
</html>

Остальная часть кода будет загружена через некоторый (async) модуль-загрузчик, такой как require.js - и весь этот код будет поступать из вашего CDN, включая require.js.

Однако даже этот маленький бит html в мгновение ока также будет поступать из CDN, если вы используете pull CDN. Поставщик CDN "pull" попадет на эту страницу всякий раз, когда он не найдет файл для html5 pushstate url в кеше.

На вашем сервере у вас должна быть какая-то маршрутизация для маршрутизации каждого запроса, который соответствует шаблону, где расширение файла не предоставляется из CDN в этот один файл.

Да, CDN попадает на сайт каждый раз, когда встречается новый url (если вы используете pull CDN), но после его получения он будет распространять его среди всех пользователей из своего кеша и не попадет на ваш сайт за тот же URL снова. Кроме того, поражение на вашем сайте у поставщика CDN будет незначительным, поскольку вы обслуживаете крошечный бит статического html. И если вы зададите заголовки своих файлов, чтобы они никогда не истекали в этом html файле (этот файл никогда не должен меняться), файл может храниться поставщиком CDN в течение очень долгого времени (в зависимости от поставщика), поэтому удары на вашем сервере в значительной степени снизится до одноразового события за уникальный URL-адрес.

Ответ 9

У этого парня была аналогичная проблема и он использовал S3/CloudFront. Все его URL перенаправляются на index.html со статусом 200.

Это обходное решение, поскольку оно включает установку index.html в качестве страницы с ошибкой.

Подробнее: https://kkob.us/2015/11/24/hosting-a-single-page-app-on-s3-with-proper-urls/