The CDN nodes don't have a separate ip for http only and for http+https, so if you try https, you're hitting a service that wasn't prepared for that. Same thing happens if you virtual host lots of http sites on a single IP with one https site: everything is fine as long as nobody tries to do https, but if they do try, they get the cert for the one site that is doing https.
The CDN's servers provide the encryption, so it would make sense that the certificate is in their name. You can't do the encryption on the origin server, because the CDN needs access to the data to be able to cache it.
I understand that point, I know you can't use the certificate on another domain by design. I'm just curious why you wouldn't issue a certificate to your CDN signed with your domain as well. It's something that bothers me about npr.org especially as it creates problems with their API for member stations wishing to go fully SSL.
But it completely breaks the certificate meaning. Imagine the bad guy giving you a fake certificate called: cdn.badguy.com and explaining that because the CDN does the encryption you can trust this domain...
I always wondered why most common KMP and RE implementations don't take into account the case of using streams instead of strings. That's why I ended up writing this article (with code) "Searching for Substrings in Streams: a Slight Modification of the Knuth-Morris-Pratt Algorithm in Haxe"  and adding information about a currently unsupported RE lib that take into account streams.
It reminds me of this article/discussion: "Fighting in front of your children - not such a bad thing?". The positive aspect is giving the whole picture of the drama, showing that things, sometimes, can be solved in a peaceful/negotiated way.
Argentina did pretty well after it defaulted its obligations in 2001 and the commodities prices significantly increased. The issues in Argentina are more related to poor infrastructure (transport, Internet, mobile, financial) and corruption.
There is a saying in Argentina that we should stop stealing for at least two years [and the country will flourish].
I just sent a message to him about this HN thread but you are always free to contact the author on their own site. He is one of the top cryptocurrencies experts right now and is engaged in many different threads/sites at the same time.
You can define things like this using s-expressions: (let mytwitter (twitter "databigbang")
Then you can do (twitterdb store (twitter.tweets)) and for every tweet your defines db is updated. Then imagine that your user is called "wslh" you can share your whole db via egont.users.wslh.twitterdb.
Building a service like IFTTT is trivial with this engine, you can also add processing rules to this stuff and share the whole data. For example, if every friend "connects" this service with their IMDB Movies Ranking, you can send all this information to a recommendation engine or just do an average of the scores between all your friends. When a friend adds a new movies everything is recalculated like in a spreadsheet.
Another use is sharing summarized information within a specific market. Imagine you work on selling ruby on rails services, you and others in your market can connect their google analytics information to Egont and provide summarized information for this specific market that helps other to take decisions based on it. You can also restrict how the information is distributed.