我们正在寻找将我们的网站/应用程序资产转移到CDN。 问题是，我们的CDN不提供带有SSL的自定义域名。 换句话说，对于SSL，它们提供https://1234.cdn.hostingcompany.com但不提供https://assets.mysite.com 。
所以这似乎是一个巨大的问题，因为我不想重新发布我的应用程序与他们的域硬编码。
所以我读了一个关于一个方法，你发送人 https://assets.mysite.com 然后redirect到https://1234.cdn.hostingcompany.com 。
这个解决scheme是否有价值，还是完全击败CDN的目的？
您可以在https://assets.mysite.com上设置自己的服务器（为该SN提供有效的SSL证书），该服务器将301redirect到https://whatever.cdn.com 。 这将适用于浏览器本身加载的任何内容。 如果你的web应用程序有JavaScript或其他东西（Flash，Silverlight等），它应该仍然有效，但你应该广泛testing。
这样做的一个很大的缺点就是所有对CDN内容的请求都会先打到你的服务器上。 数据传输将是最小的，但延迟至less是数百毫秒。 在被redirect一次之后，浏览器应该记住redirect并转到CDN的实际URL，而不会在将来出错（浏览器caching会限制这种效果）。
如果因为这是一个数据垃圾而卸载内容，这仍然是一个很好的方式来完成你想要的。 如果您正在卸载内容以获得更好的响应时间，则无法实现该目标。
正如Ceejayoz指出的那样，您可以将CDN的URL作为应用程序的configurationvariables。 硬编码的url是一个快速的方式，不可维护的意大利面代码，每个人都讨厌。
我相信它会有一个不平凡的performance，原因如下：
https://assets.mysite.com会很昂贵，需要大量的TCP往返。 在第一次连接之后，假设其他资产的请求相对较快，客户端可以重新使用连接，或者至less重新使用SSL会话，而不是进行全新的握手。 assets.mysite.com ，然后再redirect到CDN。 如果你拥有一小部分固定的资产，这可能是可以接受的。 301可能也不能很好地caching。 [需要validation] “措施，措施，措施”的通常的免责声明适用。