preload + integrity hash + cloudflare

[oleg-andreyev]

This is not something that webpack or encore related, but probably worth mention in docs that if you are using any kind of CDN that does encoding (gzip, br and etc) integrity hash will change and browser will throw a warning

A preload for '...' is found, but is not used due to an integrity mismatch.

[stof]

Integrity hashes for subresource integrity are computed based on the uncompressed assets by browsers, so the content encoding won't be an issue (requiring the integrity hash to match the compressed output would have killed any on-demand compression, which is how most compression is deployed).

My guess is that the issue is actually caused by the usage of a Cloudflare feature modifying the content of the asset dynamically, like their Auto Minify feature.

[ToshY]

@stof As someone who had issues with integrity hashes before (see symfony/webpack-encore#1164), I now get the exact same messages in my chrome console as @oleg-andreyev . Having disabled the "Auto Minify" feature for JS/CSS, disabled Rocket Loader, and everything else remotely related to asset manipulation, I'm almost certain this cannot be so easily blamed on Cloudflare now.

I've performed curl https://example.com/build/asset.css 2>/dev/null | openssl dgst -sha384 -binary | openssl base64 -A and cat ./build/asset.css 2>/dev/null| openssl dgst -sha384 -binary | openssl base64 -A, both returning the same hash as displayed by integrity attribute in the link tags.

I've done a quick search, and maybe w3c/preload#127 is somewhat related to this problem?

[carsonbot]

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

[carsonbot]

Friendly ping? Should this still be open? I will close if I don't hear anything.

[carsonbot]

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!