将任何CDN配置为只传递一个文件，无论请求的url是什么

我目前正在做一个新项目，其中整个页面应该在HTML5/JS中实现，并针对API/JSON。由于整个应用程序应该只包含一个HTML文件（index.HTML）和一个JSMVC应用程序（可能是backboneJs），我正在考虑SEO和用户友好的URL。

在那里我遇到了

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

在html5功能的帮助下，我可以定义URL，而无需真正离开或重新加载页面。但是。。。出于性能原因和低成本，我想将应用程序部署到类似Amazon CloudFount的CDN中。我不需要任何服务器基础设施（当然除了API所需的基础设施）

因此，我可以配置CDN（实际上是任何像AWS、Azure、Akamai这样的CDN）来提供相同的HTML文件吗？无论什么URL被称为

http://www.example.com=>提供index.html

http://www.example.com/any_subpage=>提供index.html

等等。。。

您可以在http://html5.gingerhost.com.但该页面的创建者可能会使用.htaccess文件或其他熟悉的文件将所有内容映射到同一个文件。我想在CDN中提供相同的功能。

任何CDN都应该具有定义源服务器的能力。如果边缘位置没有文件，CDN会联系此服务器来提供文件。

好消息是，原始服务器可以是任何为网页服务的服务器，如Apache、Nginx等。这意味着您可以应用任何类型的重写规则。

如果你不想自己设置原始服务器，你可以考虑在S3上托管你的（静态）站点。最近，他们推出了网络重定向，这可能会帮助你用不同的"别名"提供相同的文件。如果做不到这一点，您可以考虑重新定义标准错误文档，但我不确定是否仍会发送错误状态代码。

CDN旨在通过从尽可能靠近客户端的地理点提供静态资源来提供静态内容。CDN技术并不打算对请求进行重定向或服务器端处理。你需要一些其他的东西来完成这个部分。问题只是这是服务器端技术还是某种负载均衡器/防火墙请求重写（以避免使用服务器端技术）。

我不认为有一种真正的平台无关的方式可以做到这一点。您将始终绑定到服务器端技术或负载均衡器/防火墙平台。但听起来您可能已经有了这个限制，因为您需要在某个地方托管JSON API？即使你还没有决定平台，几乎任何平台都应该允许你做一些基本的路由。如果您可以提供JSONHttp请求，那么您也应该能够进行一些页面路由。

顺便说一句，我不认为你想从你的域中所有可能的URL返回你的"index.html"。您需要一些有效URL和无效URL的列表。在这种情况下，您无论如何都需要ping后端以验证请求URL。这进一步向我表明，服务器端技术将更适合这项任务，而不是在较低级别进行盲目的"包罗万象"重定向。

我个人的偏好是使用你最喜欢的MVC框架来提供具有你想要的URL结构的可索引内容（几乎所有的页面加载），然后在页面加载后使用你的JSONAPI来处理这些内容（你想做的任何动态事情）。整个过程，包括页面加载和API，都是从同一个服务器平台/环境提供的。

将404页面符号链接到索引页面。这样，当在您的网络内容上找不到请求的URL（在您的案例中出现的任何链接）时，就会提供404页面，这反过来就是索引页面本身。

# ln -s index.html 404.html

Nginx http服务器可以这样做：

location /{
    # serve a file
}

或者你可以自定义你的链接像

location /my_html{
     # serve html file
}
location /cdn/{
     # serve rest files
}

您甚至可以通过regexps 检查url

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

如果您有自己的指向CDN的域（我知道CloudFront允许您这样做），您可以使用CloudFlare（https://www.cloudflare.com/）作为用户和CDN之间的反向代理。

由于他们的免费计划，你可以创建一个规则，将所有内容重定向到index.html。我认为这是实现你想要的唯一方法，因为CDN被配置为只提供静态的现有文件，正如你所知。

如果你正在考虑SEO和友好的URL，你当然可以使用pushState来完成其中的一些。请记住：

当将所有路由重定向到index.html时，无论搜索引擎进入哪个URL，你都会向搜索引擎提供完全相同的html内容。然后，你的URL有多"SEO友好"就无关紧要了。
如果你想支持IE，它不支持History API，所以你需要一个更高级别的历史框架或其他IE解决方案。这很可能包括基于#的URL。因此，每个视图基本上都有两个不同的URL，当人们共享URL或了解搜索机器人如何捕捉到你网站的链接时，这是需要考虑的。

我建议在你过度寻找合适的云主机之前考虑以下两个选项：

将一些的数据逻辑卸载到后端，并为每个视图提供至少一些可消化的内容。你仍然可以在你的应用程序中删除或解析这些内容，并进行pushstate/jsonAPI操作以获得更好的用户体验，但你将拥有搜索引擎、opera迷你用户和其他一些不幸的浏览器的"真实"、可扫描的URL。这些静态页面不必提供相同的功能甚至样式，只需将其视为最后的回退即可。
忘记应用程序的CDN，只需将CDN用于静态文件、图像、脚本等。应用程序本身可能会出现一些问题，但真正拉动服务器的是媒体。这样做可以让你控制应用程序及其背后的服务器，但你仍然可以使用CDN来实现它的目的——提供静态内容。

我们最近联系了edgecast.com（这是一个类似cdn的cloudfront），通过他们的支持，他们告诉我这确实是他们可以做的事情，但不能通过他们的标准接口。有人告诉我，当我们需要一个到单个文件的通配符路由时，只需联系他们。

至于您的问题：是，这是可能的。只要通过他们的实时聊天联系他们，他们就会帮你，祝你好运！

更多（负面）信息：像这样的包罗万象的规则意味着一些浏览器（读取IE）所做的愚蠢的favicon.ico-forced-request将被捕获，并且普通的html页面将被再次下载。事实上，所有针对根域的自动请求（例如，iframes也请求favicon）都会被捕获，并下载常规html文件。这对你来说可能是问题，也可能不是问题，但对我来说，所有这些隐藏的请求都让我重新思考解决方案，并使用后面的Web服务器来实现真正的全面捕获。真可耻。

我和你处境相同，似乎cdn不支持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.

然而，如果你使用pull CDN，即使是这一点点html也很快就会来自CDN。CDN"拉取"提供商在其缓存中找不到html5推送状态url的文件时，就会访问此页面。

在您的服务器上，您必须有某种路由，才能将与CDN未提供文件扩展名的模式相匹配的每个请求路由到此文件。

是的，每次遇到新的url时，CDN都会访问网站（如果您使用的是pull CDN），但在它获得后，它会从缓存中将其分发给所有用户，并且不会再次访问您的网站以获取相同的url。此外，CDN提供商对您网站的影响将是微不足道的，因为您提供的是一点点静态html。而且，如果你将文件头设置为在这个html文件上永远不会过期（这个文件真的应该永远不会更改），CDN提供商可以将文件保存很长时间（取决于提供商），所以你的服务器上的点击量几乎可以归结为每个唯一url的一次事件。

这家伙也有类似的问题，使用了S3/CloudFront。他的所有网址都重定向到了index.html，并带有一个状态代码200。

这是一个解决方法，因为它涉及到将index.html设置为错误页面。

查看详细信息：https://kkob.us/2015/11/24/hosting-a-single-page-app-on-s3-with-proper-urls/

相关内容

最新更新

热门标签：