Configuring any CDN to deliver only one file no matter what url has been requested
I am currently working on a new project where the entire page should be implemented in HTML5/JS working against an API/JSON. Since the entire application should only consist of
-
I'm in the same boat as you are and it seems that the cdn's are not supporting url rewriting. The following solution does not solve our "problem" exactly but comes very close to saving $ for hosting if you're using a "pull" CDN provider.
Initial load of the default page (index.html) will provide just a tiny piece of the html, basically the bare-bones html structure, like so:
<!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>The rest of the code would be loaded via some (async) module loader like require.js -- and all of that code would come from your CDN, including require.js.
However, even this tiny bit of html in no time will also come from the CDN if you're using pull CDN. The CDN "pull" provider will hit this page whenever it does not find a file for an html5 pushstate url in its cache.
On your server you have to have some kind of routing to route every request that matches a pattern where a file extension is not provided from the CDN to this one file.
Yes, the CDN will hit the site every time a new url is encountered (if you're using pull CDN) but after it gets it, it will distribute it to all the users from its cache and will not hit your site for the same url again. Also, the hit on your site from the CDN provider will be insignificant since you're serving a tiny bit of static html. And, if you set your file headers to never expire on this html file (this file should really never change) the file can be kept by the CDN provider for a very long time (depending on the provider), so the hits on your server would pretty much come down to a one time event per a unique url.
讨论(0) -
If you’re considering SEO and friendly URLs, you can accomplish some of that using
pushState, sure. Just remember that:When redirecting all routes to index.html you will also serve the exact same html content to the search engines no matter what URL they march in on. Then it wont matter how "SEO-friendly" your URL is.
If you’re thinking IE support, it doesn’t support the History API, so you’ll need a higher-level history framework or some other workaround for IE. And that will most likely include
#-based URLs. So you will basically have two different URLs for each view, that’s something to consider when people share URLs or figuring out how search robots catches links to your site.
I would suggest considering the following two options before you go too far in finding a suitable cloud host:
Off-load some of the data logic to the backend and serve at least some digestable content for each view. You can still remove or maybe parse that content in your app and do your pushstate/jsonAPI thing for better UX, but you will have "true", scannable URLs for the search engines, opera mini users and some other unfortunate browsers. These static pages do not have to serve the same functionality or even styles, just think of it as the last fallback.
Forget about the CDN for the app, just use the CDN for static files, images, scripts etc. You can have a couple of fallbacks for the app itself, but it’s the media that really pulls the server. Doing so will put you in control over the app and the server behind it, but you can still use CDN for what it was meant for – serving static content.
讨论(0) -
Symlink your 404 page to the index page. That way, when a requested URL is not found on your web-content (about any link, as it appears in your case), the 404 page is served, which is in turn the index page itself.
# ln -s index.html 404.html讨论(0)
加载中...
- 热议问题