Content-Type在开发baidubce-sdk的时候，遇到了在不同浏览器（主要是 Firefox 和 Chrome）下调用xhr.setRequestHeader设置Request Header之后，内部的处理逻辑有一些细微的差别，导致baidubce-sdk无法正常的工作。12345varxhr =newXMLHttpRequest();xhr.setRequestHeader('Content-Type','foo/bar');// 当Method !== 'GET' 的时候xhr.open('POST','',true);xhr.send('');对于上面这段儿代码，因为我们显式的设置了Content-Type，所以我们期望的是服务器收到的Request Header中Content-Type应该是foo/bar，实际上在Firefox里面会自动添加charset=UTF-8，也就是服务器得到的信息是foo/bar; charset=UTF-8因为根据 ak 和 sk 计算签名的时候，Content-Type作为其中的一个因子参与计算的。Firefox下面的这个问题，导致 client 和 server 计算出来的签名不一致，所以 server 就拒绝了某些请求。Content-Length第二个兼容性的问题是关于Content-Length的，因为baidubce-sdk最初的是为Node.js开发的，通过browserify处理之后直接运行在浏览器里面。在Node.js里面，我们直接使用的require('http')模块，可以任意设置Request Header里面的字段，但是在XMLHttpRequest的文档里面，限制了一些可以设置的Header。在GET请求里面，Content-Length值是0，此时 client 是有这个信息的，因此会把Content-Length作为计算签名的一个因子，不过因为xhr的限制，我们无法设置这个 Header，因此 server 收到的GET请求里面，Request Header里面是没有这个Content-Length的，这也就导致了签名计算不一致的问题。baidubce-sdk问题都描述清楚了，对应的解决方案也就有了：Content-Type：在POST的时候给所有浏览器下面都加上; charset=UTF-8这部分信息使用sendAsBinary代替send，不过browserify生成的代码里面没有调用这个API，需要自己去修改一下才可以。调用xhr.send参数的时候，不要传递string，改成Uint8Array，也可以避免这个问题。Content-Length这个问题会判断一下GET和0的情况来决定是否让Content-Length来参与计算签名广告贴来了baidubce-sdk封装了百度开放云提供的一些基础API，比如云存储(BOS)，音视频转码（Media），欢迎有这方面需求的童鞋试用。1npmibaidubce-sdk参考https://bugzilla.mozilla.org/show_bug.cgi?id=416178