static hostname exposure
midnight-wonderer opened this issue · comments
Background
There are some less known fact of jsdelivr in this repository
it is the configurable server list in app.js
https://github.com/jsdelivr/dns-openmix/blob/98577678e8b1574563afc69d89654cc3c2117a62/app.js
I can access some specific cdn with the hostname
e.g.
I can access
http://jsdelivr-cb7.kxcdn.com/react/0.13.1/react.min.js
from keycdn
but there are some issues
- It is not official and not document anywhere.
- It not works with all cdn in the pool
- https is not supported on some cdn as the certificate does not match the hostname.
What I want?
I want to force client to download form certain cdn instead of relying on RUM DNS mechanism.
What's the point?
- Reliability is more importance than speed
The thing is no cdn is perfect that why you use RUM to select the CDN by DNS.
However, there is already available javascript mechanism for that which is more robust than the DNS solution. It is Asynchronous Module Definition and it's already implemented by majority of javascript hosted by jsdelivr. - Few choice Available
Currently cdnjs and jsdelivr is the only choice for not so popular javascript CDN. If I use Asynchronous Module Definition to failover from cdnjs to jsdelivr. What if RUM data indicated that cdnjs is the fastest cdn for the region? It is practically mean no robust failover mechanism possible.
The solution
I'm not sure if this practical but the solution is to document the static hostname somewhere (no need to do this for all available bandwidth providers actually just MaxCDN is enough but more is better)
also make sure that the hostname has https support and never change.
Is this possible?
I think you completely miss-understood how jsDelivr load-balancing works based on RUM.
I recommend you to read https://hacks.mozilla.org/2014/03/jsdelivr-the-advanced-open-source-public-cdn/
AMD has nothing to do here, please read that article. Unless im missing something then feel free to correct me
Hi @jimaek I read the article long time ago and just reread it after you mention. I'm not sure where specifically you want me to look at. I just assumed you mean RUM is so reliable and precise so no need for any other fallback mechanism? (not so sure if this what you mean)
FWIW it isn't.
There are several times I witness 1 ~ 2 min jQuery loading from jsDelivr from my place.
I have some theory behind that (it's not about network latency) but let put that aside.
The point is RUM is less reliable than AMD for making a decision and in some case it get in a way.
I just suggest jsDelivr to not mandate the use of RUM for the implementation that already have AMD in place.
Some context: AMD can fallback if the library took too long to load or not available
more info here:
http://requirejs.org/docs/api.html#pathsfallbacks
However, after I post this issue I just found out that MaxCDN guys already implement what I described I just have to change hostname from
cdn.jsdelivr.net
to
oss.maxcdn.com
and the traffic will guaranteed to hit MaxCDN PoPs
e.g.
http://oss.maxcdn.com/react/0.13.1/react.min.js
It is good to see this happen to other PoPs (apart from MaxCDN) too.
I see your point but thats not the solution. If you are not hitting the correct POP locations and have slow downloads then we should fix our load balancing to make you hit the correct CDNs. This is a problem that needs to be fixed and not avoided like you suggest.
Simply forcing different CDNs is a bad idea and is not the point of jsDelivr (what if oss.maxcdn.com goes down?)