TypeError on Request.integrity with no-cors mode is a foot gun

[wanderview]

It seems a lot of people trying to use SRI with service workers where Request.integrity is implemented are running into problems:

https://bugzilla.mozilla.org/show_bug.cgi?id=1393439

The issue is that its pretty common to do <script integrity="hash"> in your document. This creates a no-cors request by default. If their service worker script passes through with fetch(evt.request) then they will get a TypeError. This is required by step 32.3 here:

https://fetch.spec.whatwg.org/#dom-request

Perhaps we should move this check out of the Request() constructor and into the fetch algorithm at the point an opaque Response is created. It seems its only really important if we are going to be returning an opaque Response and need to hide any information leakage about the contents.

[annevk]

The Fetch algorithm already requires that the integrity check fails on an opaque response.

I agree that we should remove this exception as we've already removed similar exceptions in the past. Do you know which tests need to be updated or are you willing to update them in the eventual Firefox patch?

[wanderview]

Note, we are going to move forward with this fix since its impacting sites. Also, I'm asking Tom to add a WPT test in gecko that will be sync'ed upstream.

[annevk]

Thanks @wanderview, sounds good. Once that's done I'll merge this since Chrome hasn't implemented integrity yet it sounds like and they probably want to do the same as us.

cc @tyoshino @jakearchibald

[nico3333fr]

Just wanted to say thank you for moving on quickly on this, my 2 websites that are impacted say thanks too ;)

[rakuco]

For future reference: Chromium's tracking bug is https://bugs.chromium.org/p/chromium/issues/detail?id=766975. There's some flakiness with the WPT changes that landed a few days ago, but I'm still checking if it's caused by the tests or Blink.