我使用 srihash.org 生成了以下代码网址 https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js :
<script src="https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js"
integrity="sha384-CAN0Iz/H09oATWPeJZclEOAM/nF1cq3DSuAbxi9IMbZIx8m3ERInrpuk11n+lHRq"
crossorigin="anonymous"></script>
当尝试加载包含完整性检查脚本的页面时，我在 Windows 上的 Chrome 50 中收到以下错误:
Failed to find a valid digest in the 'integrity' attribute for resource 'https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js' with computed SHA-256 integrity 'vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU='. The resource has been blocked.
我还尝试手动生成哈希(同样，在 Windows 上，openssl-1.0.2h)，使用:
openssl dgst -sha384 -binary Cesium.js | openssl base64 -A
结果:
X5EHALkqk8r9hyCKwav7y+6BOUg2dRH90/qSxdytan2SQQB9g8jsYYWLDKzNeKx4
当使用 Chrome 加载 Cesium.js 时，此哈希有效。然而，这提出了一个问题，这两个哈希值中哪一个是正确的……排除中间人攻击的可能性，我认为它与行结尾或编码有关。 Cesium.js 似乎有 Windows 行结尾，下面附有在 Chrome 中加载它的 HTTP 响应。
如何解释这两个哈希值之间的差异，哪一个是正确的？
Cesium.js 的 HTTP 响应 header :
HTTP/1.1 200 OK
Cache-Control: max-age=172800
Content-Length: 494091
Content-Type: application/javascript
Content-Encoding: gzip
Last-Modified: Mon, 02 May 2016 15:12:32 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/8.5
x-amz-id-2: giU2DeYQi87OAkuyr2qKeZx8KRihIY7TV9qcJShi/YVl+C5K50mHeSLFWYhA8k5Oc+A50Oxjh/4=
x-amz-request-id: 112881D9D52248F6
X-Powered-By: ARR/3.0
X-UA-Compatible: IE=edge
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type,X-Requested-With
Date: Mon, 30 May 2016 12:49:46 GMT
最佳答案
经过一番挖掘，我发现 srihash.org 生成的哈希值不正确。
错误的结果是由两个因素共同造成的:
Cesium.js来自 cesiumjs.org 的请求始终使用
Content-Encoding: gzip提供服务，即使请求不包含Accept-Encoding: gzip。srihash.org(参见 source )使用 xhr2获取资源，其中does not support gzip encoding .
关于javascript - srihash.org 不适用于 cesiumjs.org 中的 .js 文件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37527029/