Search code examples
blazor-webassembly.net-7.0

Content validation problem in a "blazor + wasm + pwa" setup

I have a blazor+wasm+pwa application hosted at a provider under IIS with out-of-process model. The framework contains a file named _framework/dotnet.timezones.blat. Others are most likely affected too, but this is where loading fails first. When fetched, it yields:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://app.x.y.z/_framework/dotnet.timezones.blat' with computed SHA-256 integrity 'rwyJqJu36keQwNmm/O1XV7tnkkVldIOK8GIjn4gTUt4='. The resource has been blocked.

  • The file uploaded with FTP has a different hash: GzDmKQksbAkzNe1GNrGcVtpc0naGXOFCpUzq3c/pV+c=.
  • The previous version, which was never uploaded to that subdomain has that specific hash.
  • The previous version was uploaded to another hosted site at the same provider but the IP addresses are different, hence the IIS instances should be different too.
  • If I download the file with any other tool (other than a browser), I get the correct one, with the correct hash.
  • If I download the file from within the browser, I get the old one, having the calculated hash, but that does not match with the hash in service-worker-assets.js
  • Ok, It should be cached somewhere. But I have deleted all cache. I have tried other browsers: Edge, Chrome, Waterfox, and Firefox. Instances, I have never used to load any version of that application from any source. I have even tried loading it on a clean VM! No change.

I am going nuts... where is it taking that version from?

[Update]

I have figured out where it is coming from: after publishing, the plain dotnet.timezones.blat file is ok, but the content of the created .gz is the old version (most likely the .br is affected too, but I don't know that format)! Hence, since my other tool does not accept compressed files, I got the original file. The browser accepts compressed files, hence I get the compressed one with the old content. I have tried deleting the bin, obj and .vs folders, to no avail.

Now the question is: how can I force the build/publish process to recompress those files? Are they cached somewhere or are they part of the SDK?

Solution

  • It is quite annoying that this issue persists. As far as I can tell, installing an update to the SDK will cause this. Unfortunately, I could not figure out where the SDK is caching these files. But even if the build process descriptor could be altered, it would still reappear after an update. This is why I made a dotnet tool that can be used to do the job. As it is a published tool, making it part of the project configuration and the build (publish) process is simple.

    For anybody having the same issues, take a look here: https://github.com/zorgoz/PreCompress