Issue with <link rel="preload"> about webpack-subresource-integrity

[josephliccini]

I did some testing, and it looks like Firefox, Safari, and Edge are fine, just Chrome has this issue.

[jscheid]

Hi, thanks for bringing this to my attention. I've got a lot going on this week but hoping to take a closer look next week.

In addition to the README change you suggested, perhaps we should detect when /* webpackPreload: "true" */ is used and warn if so?

Do I understand correctly that adding SRI to <link rel="preload"> would not be helpful at this point?

Also, does "breaking the preloading mechanism" mean what I think it means - that the page still works, but without preloading?

I'm also curious about what you mean by double-fetch. It probably isn't necessary for me to understand but I'd like to know how that would come about in your case, if you wouldn't mind going into a bit more detail.

[jscheid]

I've investigated this a bit more and found the following (all tested with the current release of the plugin, 1.3.2 -- the upcoming 1.3.3 doesn't make any changes to preload handling so should be identical):

Safari 12.1.2 (14607.3.9)

No warnings, loads resource once, preloads correctly, regardless of whether integrity is specified on the link tag.

Firefox 68.0.2

No warnings, preloads correctly (requires network.preload setting to be enabled) but only if integrity is added to the link rel="preload" tag. Without integrity the resource gets loaded twice.

Chrome 76.0.3809.132

Prints a warning about integrity mismatch (and another one about the resource not being used in time) regardless of whether integrity is present on the preload tag or not. (I've tried a few things, such as HTTP/2, to see if I can make it work but doesn't seem to make a difference.)

Based on the above and on the recent spec changes discussed in the ticket you linked to, @josephliccini, we should add integrity to link tags to make things work correctly on Firefox and (hopefully) future Chrome versions.

I'm planning to release that in version 1.4.0 some time in the near future. Since the feature is either broken or behind a feature flag, it doesn't appear to be urgent. In the meantime, I've added the warning to the README as you've suggested.