search

symfony / webpack-encore-bundle

Symfony integration with Webpack Encore!
https://symfony.com/webpack-encore
MIT License
940 stars 83 forks source link

preload + integrity hash + cloudflare #220

Open oleg-andreyev opened 1 year ago

oleg-andreyev commented 1 year ago

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 commented 1 year ago

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 commented 11 months ago

@stof As someone who had issues with integrity hashes before (see https://github.com/symfony/webpack-encore/issues/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 https://github.com/w3c/preload/issues/127 is somewhat related to this problem?