srihash.org 不适用于来自 cesiumjs.org 的 .js 文件
srihash.org not working for .js file from cesiumjs.org
我使用 srihash.org for URL 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>
尝试加载包含 integrity-checked 脚本的页面时，我在 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 时，此哈希有效。然而，这提出了两个哈希值中哪一个是正确的问题......排除了 MITM-attack 不太可能的可能性，我认为它与行尾或编码有关。 Cesium.js 似乎有 Windows 行结尾，在 Chrome 中加载它的 HTTP 响应附在下面。
如何解释这两个哈希之间的差异，哪个是正确的？
Cesium.js 的 HTTP 响应 headers:
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
如您所料，这显然是一个与编码相关的 chrome 错误。其他人报告其他脚本的问题。
检查 this bug page chrome 和 openssl 之间的不一致。
作为临时解决方法，我会添加
vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU=
到您信任的 SHA256 完整性属性（在验证下载的脚本实际上是正确的之后）。
Chrome 可能在解压缩之前使用特殊编码计算此哈希。
经过一番挖掘，我发现 srihash.org 生成的哈希值不正确。
不正确的结果是由于两个因素的结合：
来自 cesiumjs.org 的 Cesium.js 始终与 Content-Encoding: gzip 一起提供，即使请求不包含 Accept-Encoding: gzip.
srihash.org（参见 source) uses xhr2 to fetch resources, which does not support gzip encoding。
我使用 srihash.org for URL 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>
尝试加载包含 integrity-checked 脚本的页面时，我在 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 时，此哈希有效。然而，这提出了两个哈希值中哪一个是正确的问题......排除了 MITM-attack 不太可能的可能性，我认为它与行尾或编码有关。 Cesium.js 似乎有 Windows 行结尾，在 Chrome 中加载它的 HTTP 响应附在下面。
如何解释这两个哈希之间的差异，哪个是正确的？
Cesium.js 的 HTTP 响应 headers:
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
如您所料，这显然是一个与编码相关的 chrome 错误。其他人报告其他脚本的问题。
检查 this bug page chrome 和 openssl 之间的不一致。
作为临时解决方法，我会添加
vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU=
到您信任的 SHA256 完整性属性（在验证下载的脚本实际上是正确的之后）。
Chrome 可能在解压缩之前使用特殊编码计算此哈希。
经过一番挖掘，我发现 srihash.org 生成的哈希值不正确。
不正确的结果是由于两个因素的结合：
-
来自 cesiumjs.org 的
Cesium.js 始终与
Content-Encoding: gzip一起提供，即使请求不包含Accept-Encoding: gzip.srihash.org（参见 source) uses xhr2 to fetch resources, which does not support gzip encoding。