1855170 - rel=preload failures should not be retried

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Happens for <script> in https://bugzilla.mozilla.org/show_bug.cgi?id=1854468. See https://bugzilla.mozilla.org/show_bug.cgi?id=1854468#c8 and https://bugzilla.mozilla.org/show_bug.cgi?id=1854468#c12.

Requesting it again seems unnecessary.

Comment 1

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

How is the desired behavior here for other resources, e.g. CSS files?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

Do I understand this correctly: the problem is that if the dummy file doesn't exist, we first try to do a preload, then we try again when parsing the HTML file?
If the file exists we just load it the first time?

Comment 3

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

Do I understand this correctly: the problem is that if the dummy file doesn't exist, we first try to do a preload,

Yes.

then we try again when parsing the HTML file?

Don't know when exactly. Only know that it's tried again.

If the file exists we just load it the first time?

It seems so. Although it could be that the load just happens later.

Comment 4

[Valentin Gosu [:valentin] (he/him)]

I think this is a general rel=preload issue.
The problem is that once the preload fails, it usually gets removed from the preloads and then we do a second one. I think we do cache the 404 result if it has the appropriate headers, but normally we'd do a second request. 🤷
I don't think this is a necko bug.

This should really be fixed in the places that issue the preloads like here

Also, there is this note in the spec.
https://html.spec.whatwg.org/multipage/links.html#link-type-preload

It is important that network errors are added to the preload cache so that if a preload request results in an error, the erroneous response isn't re-requested from the network later. This also has security implications; consider the case where a developer specifies subresource integrity metadata on a preload request, but not the following resource request. If the preload request fails subresource integrity verification and is discarded, the resource request will fetch and consume a potentially-malicious response from the network without verifying its integrity. [SRI]

Comment 5

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Removing the severity and priority so that the responsible team may set them. Hope that's okay.