从CDN而不是您自己的服务器提供javascript库具有巨大的优势.减少服务器的工作量,CDN可能会比服务器更接近用户,但最重要的是用户的浏览器很可能已经从该URL缓存了它.最后一个意味着每个人的总工作量减少,所以它显然是一个全面的胜利,更有可能我们(开发人员)更多地依靠CDN来服务我们的javascript.
但是流行的javascript CDN(谷歌,微软,其他？)只托管少量文件.对于其他人,我们可以选择自己托管它们,或者......使用源代码控制服务器作为一种CDN.这是不太可能Github上或类似的具有全球拥有优化后的文件的地理分布缓存.但是,如果这是常见的做法,那么用户的浏览器就有可能将其缓存.从我们的服务器到github的卸载工作的论点只有在Github愿意自愿这样做的情况下才有效.
那么,这是常见的做法吗？我们应该互相鼓励这样做吗？Github介意吗？他们是否有正式的政策声明？
JS的新手,我也学习使用加密库.我不明白为什么使用相同的秘密签署/编码相同的消息会产生不同的结果.
我使用jsSHA 1.3.1这里找到,而这里所描述CryptoJS 3.0.2试图建立一个base64的SHA-1编码的HMAC签名.这是代码:
在HTML ...
<script src="lib/jsSHA/src/sha1.js"></script>
<script src="http://crypto-js.googlecode.com/svn/tags/3.0.2/build/rollups/hmac-sha1.js"></script>
在js ...
var message = "shah me";
var secret = "hide me";
var crypto = CryptoJS.HmacSHA1(message, secret).toString(CryptoJS.enc.Base64) + '=';
var shaObj = new jsSHA(message, "ASCII");
var jssha = shaObj.getHMAC(secret, "ASCII", "B64") + '=';
return "crypto answer is " + crypto + " jssha answer is " + jssha;
你能帮我解释一下这些结果有何不同吗？
加密答案是3e929e69920fb7d423f816bfcd6654484f1f6d56 = jssha答案是PpKeaZIPt9Qj + Ba/zWZUSE8fbVY =
更重要的是,这两者都与我在轨道中生成的签名不同,就像这样......
digest = OpenSSL::Digest::Digest.new('sha1')
raw_signature = OpenSSL::HMAC.digest(digest, "hide me","shah me")
b64_signature …