Preload: only allow certain values for the `as` attribute #10212

noamr · 2024-03-19T15:31:54Z

At least two implementers are interested (and none opposed):
- This reflects the status of existing implementations, apart from the json value which is new.
Tests are written and can be reviewed and commented upon at:
- Update supported-as-values.html: json should not be supported web-platform-tests/wpt#45426
Implementation bugs are filed:
- Chromium: WAI
- Gecko: WAI
- WebKit: WAI
MDN issue is filed: Update link rel preload to reflect browser support mdn/content#32740
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/links.html ( diff )
/semantics.html ( diff )

source

domenic

Looks good with nits. Although I wonder what the deal is with json and whether adding that to the spec was a mistake since nobody seems to be working on implementing it?

source

noamr · 2024-03-26T08:45:18Z

Looks good with nits. Although I wonder what the deal is with json and whether adding that to the spec was a mistake since nobody seems to be working on implementing it?

This seems like "somebody is working on implementing it", no?

tunetheweb · 2024-03-26T11:55:40Z

I wonder if we should leave JSON off until implementers implement that? Just having it as a destination does not mean it works for preload (the whole point of this PR is to make that clear!) so I'm not sure that as=json is currently different to any of the other valid destination values that don't currently work for preload?

noamr · 2024-03-26T13:12:06Z

I wonder if we should leave JSON off until implementers implement that? Just having it as a destination does not mean it works for preload (the whole point of this PR is to make that clear!) so I'm not sure that as=json is currently different to any of the other valid destination values that don't currently work for preload?

It's implemented and tested, at least in part: web-platform-tests/wpt#41665

tunetheweb · 2024-03-26T13:30:02Z

I beg to differ:

https://wpt.fyi/results/preload?label=experimental&label=master&aligned

https://wpt.fyi/results/preload/supported-as-values.html%3Fas%3Djson%26expected%3D1?label=experimental&label=master&aligned

But I do agree having WPT is a good first start so seems the intent is to eventually support this?

domenic · 2024-03-27T01:49:26Z

This seems like "somebody is working on implementing it", no?

I can't tell. It says the issue is fixed, so I anticipate no more work will happen on it. But, the WPT still doesn't pass. Maybe @nicolo-ribaudo can clarify?

noamr · 2024-03-27T13:12:21Z

Removed as=json from the spec for the time being, we can add it when it's implemented anywhere.

nicolo-ribaudo · 2024-03-28T11:22:04Z

I originally added as=json just because all destinations were exposed (#9486 (comment)). Then I didn't implement in Chromium it while working on https://issues.chromium.org/issues/40285036 just because... I forgot 😅

The use case for JSON is that you might want to pre-download your full JS modules graph (i.e. same use case as rel="script"), however JSON modules are always leaves of the graph so they don't cause waterfalls: not preloading them is not as bad as not preloading JS modules.

If we want to support it, we should also make sure that <link rel=modulepreload as=json> works. I can open an issue to discuss it, but I don't have a preference regarding keeping rel=preload as=json or not until when we reach a conclusion on that.

noamr · 2024-03-28T11:43:03Z

I originally added as=json just because all destinations were exposed (#9486 (comment)). Then I didn't implement in Chromium it while working on https://issues.chromium.org/issues/40285036 just because... I forgot 😅

The use case for JSON is that you might want to pre-download your full JS modules graph (i.e. same use case as rel="script"), however JSON modules are always leaves of the graph so they don't cause waterfalls: not preloading them is not as bad as not preloading JS modules.

If we want to support it, we should also make sure that <link rel=modulepreload as=json> works. I can open an issue to discuss it, but I don't have a preference regarding keeping rel=preload as=json or not until when we reach a conclusion on that.

OK, thinking about this again, since JSON is a module-thing, it only makes sense when preloading a module graph (modulepreload). Since modulepreload anyway doesn't have as, this should be done automatically when parsing the module that uses the JSON. In either case, having <link rel=preload as=json> doesn't add much. I removed it from the spec and will remove from WPT.

tunetheweb · 2024-03-28T11:45:20Z

Can we leave it in WPT (it's helpful to know what's NOT supported - and would have saved me writing a test case if I'd thought to look there) but change it from expected=1 to expected=0 like the other ones that are not supported?

nicolo-ribaudo · 2024-03-28T11:52:39Z

OK, thinking about this again, since JSON is a module-thing, it only makes sense when preloading a module graph (modulepreload).
Since modulepreload anyway doesn't have as, this should be done automatically when parsing the module that uses the JSON

modulepreload has as (see step 3 of https://html.spec.whatwg.org/#link-type-modulepreload), and actually by reading that algorithm I think currently <link rel=modulepreload as=json> is specified to pre-load the JSON module and add it to the import map (even if it was not my intention when adding the JSON destination, because I didn't think about it).

Also, modulepreload doesn't guarantee that the dependencies of a module will be preloaded too, it's a potential transparent optimization that browsers can implement. The recommendation is to explicitly list all the dependencies in separate link rel=modulepreload tags.

noamr · 2024-03-28T12:18:38Z

OK, thinking about this again, since JSON is a module-thing, it only makes sense when preloading a module graph (modulepreload).

Since modulepreload anyway doesn't have as, this should be done automatically when parsing the module that uses the JSON

modulepreload has as (see step 3 of https://html.spec.whatwg.org/#link-type-modulepreload), and actually by reading that algorithm I think currently <link rel=modulepreload as=json> is specified to pre-load the JSON module and add it to the import map (even if it was not my intention when adding the JSON destination, because I didn't think about it).

Also, modulepreload doesn't guarantee that the dependencies of a module will be preloaded too, it's a potential transparent optimization that browsers can implement. The recommendation is to explicitly list all the dependencies in separate link rel=modulepreload tags.

Gotcha, makes sense. Anyway, all of that is beyond the scope of this patch.

domenic

Spec text LGTM. Let me know when the tests are updated for JSON.

noamr · 2024-03-29T09:26:00Z

Spec text LGTM. Let me know when the tests are updated for JSON.

Done (web-platform-tests/wpt#45426)

…b.html. In the WPT PR 41665 [1], preload-csp.sub.html was added connect-src:'none' in the CSP [2], the reason is that the json modules will use 'connect-src' as the CSP directive, see the destination "json" in [3]. However, this test calls "hasArrivedAtServer" to verify the result [4], which uses 'fetch()' API. [5] And according the CSP spec, the directive for fetch() is "connect-src" (See the empty string in [3]) Hence the change introduced in [2] causes the call to fetch() will violate the CSP restriction, and causes the test failed on all browser vendors. [6] Further check the history on the wpt.fyi in [6], we can find out all browsers started to fail since Oct.31.2023, which is also the date the PR 41665 [1] is merged into master [7]. Now back to the test itself, since preloading json modules is not allowed in previous patch D234849 [8] and whatwg PR 10212 [9], we can just simply remove the connect-src: 'none' CSP directive. [1]: #41665 [2]: 40db1c8#diff-18344ffd5be3dce2faabd52b30c10d3c7beeef3a024eac638c8e0e71b07bb7c6R2 [3]: https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request [4]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/preload-csp.sub.html#L33 [5]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/resources/preload_helper.js#L10 [6]: https://wpt.fyi/results/preload/preload-csp.sub.html?label=experimental&label=master&aligned [7]: 40db1c8 [8]: https://phabricator.services.mozilla.com/D234849 [9]: whatwg/html#10212 Differential Revision: https://phabricator.services.mozilla.com/D235314 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1940382 gecko-commit: 55b5b1beb2a8901e30af5d9f6f2fb4b6122be5b8 gecko-reviewers: dom-core, farre

…viewers,valentin,farre Implement whatwg/html#10212 Disallow preloading for "json". https://html.spec.whatwg.org/#translate-a-preload-destination And add mime-type check for JSON files. Differential Revision: https://phabricator.services.mozilla.com/D234849

…preload-csp.sub.html. r=dom-core,farre In the WPT PR 41665 [1], preload-csp.sub.html was added connect-src:'none' in the CSP [2], the reason is that the json modules will use 'connect-src' as the CSP directive, see the destination "json" in [3]. However, this test calls "hasArrivedAtServer" to verify the result [4], which uses 'fetch()' API. [5] And according the CSP spec, the directive for fetch() is "connect-src" (See the empty string in [3]) Hence the change introduced in [2] causes the call to fetch() will violate the CSP restriction, and causes the test failed on all browser vendors. [6] Further check the history on the wpt.fyi in [6], we can find out all browsers started to fail since Oct.31.2023, which is also the date the PR 41665 [1] is merged into master [7]. Now back to the test itself, since preloading json modules is not allowed in previous patch D234849 [8] and whatwg PR 10212 [9], we can just simply remove the connect-src: 'none' CSP directive. [1]: web-platform-tests/wpt#41665 [2]: web-platform-tests/wpt@40db1c8#diff-18344ffd5be3dce2faabd52b30c10d3c7beeef3a024eac638c8e0e71b07bb7c6R2 [3]: https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request [4]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/preload-csp.sub.html#L33 [5]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/resources/preload_helper.js#L10 [6]: https://wpt.fyi/results/preload/preload-csp.sub.html?label=experimental&label=master&aligned [7]: web-platform-tests/wpt@40db1c8 [8]: https://phabricator.services.mozilla.com/D234849 [9]: whatwg/html#10212 Differential Revision: https://phabricator.services.mozilla.com/D235314

…viewers,valentin,farre Implement whatwg/html#10212 Disallow preloading for "json". https://html.spec.whatwg.org/#translate-a-preload-destination And add mime-type check for JSON files. Differential Revision: https://phabricator.services.mozilla.com/D234849

…preload-csp.sub.html. r=dom-core,farre In the WPT PR 41665 [1], preload-csp.sub.html was added connect-src:'none' in the CSP [2], the reason is that the json modules will use 'connect-src' as the CSP directive, see the destination "json" in [3]. However, this test calls "hasArrivedAtServer" to verify the result [4], which uses 'fetch()' API. [5] And according the CSP spec, the directive for fetch() is "connect-src" (See the empty string in [3]) Hence the change introduced in [2] causes the call to fetch() will violate the CSP restriction, and causes the test failed on all browser vendors. [6] Further check the history on the wpt.fyi in [6], we can find out all browsers started to fail since Oct.31.2023, which is also the date the PR 41665 [1] is merged into master [7]. Now back to the test itself, since preloading json modules is not allowed in previous patch D234849 [8] and whatwg PR 10212 [9], we can just simply remove the connect-src: 'none' CSP directive. [1]: web-platform-tests/wpt#41665 [2]: web-platform-tests/wpt@40db1c8#diff-18344ffd5be3dce2faabd52b30c10d3c7beeef3a024eac638c8e0e71b07bb7c6R2 [3]: https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request [4]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/preload-csp.sub.html#L33 [5]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/resources/preload_helper.js#L10 [6]: https://wpt.fyi/results/preload/preload-csp.sub.html?label=experimental&label=master&aligned [7]: web-platform-tests/wpt@40db1c8 [8]: https://phabricator.services.mozilla.com/D234849 [9]: whatwg/html#10212 Differential Revision: https://phabricator.services.mozilla.com/D235314

…b.html. In the WPT PR 41665 [1], preload-csp.sub.html was added connect-src:'none' in the CSP [2], the reason is that the json modules will use 'connect-src' as the CSP directive, see the destination "json" in [3]. However, this test calls "hasArrivedAtServer" to verify the result [4], which uses 'fetch()' API. [5] And according the CSP spec, the directive for fetch() is "connect-src" (See the empty string in [3]) Hence the change introduced in [2] causes the call to fetch() will violate the CSP restriction, and causes the test failed on all browser vendors. [6] Further check the history on the wpt.fyi in [6], we can find out all browsers started to fail since Oct.31.2023, which is also the date the PR 41665 [1] is merged into master [7]. Now back to the test itself, since preloading json modules is not allowed in previous patch D234849 [8] and whatwg PR 10212 [9], we can just simply remove the connect-src: 'none' CSP directive. [1]: #41665 [2]: 40db1c8#diff-18344ffd5be3dce2faabd52b30c10d3c7beeef3a024eac638c8e0e71b07bb7c6R2 [3]: https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request [4]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/preload-csp.sub.html#L33 [5]: https://github.com/web-platform-tests/wpt/blob/803b53367671fef86957c611a38e1d145044a97c/preload/resources/preload_helper.js#L10 [6]: https://wpt.fyi/results/preload/preload-csp.sub.html?label=experimental&label=master&aligned [7]: 40db1c8 [8]: https://phabricator.services.mozilla.com/D234849 [9]: whatwg/html#10212 Differential Revision: https://phabricator.services.mozilla.com/D235314 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1940382 gecko-commit: 55b5b1beb2a8901e30af5d9f6f2fb4b6122be5b8 gecko-reviewers: dom-core, farre

Preload: only allow certain values for the as attribute

a8eac2d

Closes whatwg#8332

noamr mentioned this pull request Mar 19, 2024

Test the supported values of <link rel=preload as> web-platform-tests/wpt#45200

Merged

tunetheweb reviewed Mar 19, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

Accept @tunetheweb's edit

48d1f85

noamr requested a review from annevk March 19, 2024 16:07

domenic reviewed Mar 26, 2024

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

nits

4d7a5d0

Remove as=json for the time being

49d1a3e

domenic approved these changes Mar 29, 2024

View reviewed changes

domenic merged commit aa0f4e8 into whatwg:main Apr 1, 2024
2 checks passed

domenic added the topic: resource hints (inc. preload) label Apr 1, 2024

YusukeHirao mentioned this pull request Aug 12, 2024

Modify Enumerated Values of the as Attribute Based on Link Type markuplint/markuplint#1987

Open

allstarschh mentioned this pull request Jan 22, 2025

An event handler for <link rel=preload as=json>? #10940

Open

moz-wptsync-bot mentioned this pull request Feb 10, 2025

[Gecko Bug 1940382] Part 4: Remove connect-src:'none' restriction from the preload-csp.sub.html. web-platform-tests/wpt#50605

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Preload: only allow certain values for the `as` attribute #10212

Preload: only allow certain values for the `as` attribute #10212

noamr commented Mar 19, 2024 •

edited by pr-preview bot

Loading

domenic left a comment

noamr commented Mar 26, 2024 •

edited

Loading

tunetheweb commented Mar 26, 2024

noamr commented Mar 26, 2024

tunetheweb commented Mar 26, 2024

domenic commented Mar 27, 2024

noamr commented Mar 27, 2024

nicolo-ribaudo commented Mar 28, 2024

noamr commented Mar 28, 2024

tunetheweb commented Mar 28, 2024

nicolo-ribaudo commented Mar 28, 2024

noamr commented Mar 28, 2024

domenic left a comment

noamr commented Mar 29, 2024

Preload: only allow certain values for the as attribute #10212

Preload: only allow certain values for the as attribute #10212

Conversation

noamr commented Mar 19, 2024 • edited by pr-preview bot Loading

domenic left a comment

Choose a reason for hiding this comment

noamr commented Mar 26, 2024 • edited Loading

tunetheweb commented Mar 26, 2024

noamr commented Mar 26, 2024

tunetheweb commented Mar 26, 2024

domenic commented Mar 27, 2024

noamr commented Mar 27, 2024

nicolo-ribaudo commented Mar 28, 2024

noamr commented Mar 28, 2024

tunetheweb commented Mar 28, 2024

nicolo-ribaudo commented Mar 28, 2024

noamr commented Mar 28, 2024

domenic left a comment

Choose a reason for hiding this comment

noamr commented Mar 29, 2024

Preload: only allow certain values for the `as` attribute #10212

Preload: only allow certain values for the `as` attribute #10212

noamr commented Mar 19, 2024 •

edited by pr-preview bot

Loading

noamr commented Mar 26, 2024 •

edited

Loading