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

Question

В настоящее время я работаю над новым проектом, где вся страница должна быть реализована в 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.

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

# ln -s index.html 404.html

Answer 4

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

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

<!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>

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

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

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

Answer 7

Http-сервер Nginx может сделать это следующим образом:

location /{
    # serve a file
}

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

location /my_html{
     # serve html file
}

location /cdn/{
     # serve rest files
}

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

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

Answer 8

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

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

Еще немного (отрицательной) информации: Правило "поймать все", подобное этому, означает, что глупый favicon.ico-вынужденный запрос, который делают некоторые браузеры (читайте IE), будет перехвачен, и обычная html-страница будет загружена снова. Фактически, все автоматические запросы (например, iframes также запрашивают favicon) к корневому домену будут перехвачены и будет загружен обычный html-файл. Это может или не может быть проблемой для вас, но для меня все эти скрытые запросы заставляют меня переосмыслить решение и использовать веб-сервер позади, чтобы сделать фактическую ловушку. Стыд действительно.

Answer 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/