Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 91e378989bbd67d18f7c691c40c3c085926e63e0
https://github.com/WebKit/WebKit/commit/91e378989bbd67d18f7c691c40c3c085926e63e0
Author: Ahmad Saleem <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M LayoutTests/http/tests/preload/link-header-on-subresource.html
A LayoutTests/http/tests/preload/resources/dummy.js
A
LayoutTests/imported/w3c/web-platform-tests/preload/cross-origin-link-header-on-subresource.sub-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/preload/cross-origin-link-header-on-subresource.sub.html
M Source/WebCore/loader/SubresourceLoader.cpp
Log Message:
-----------
Preloading script from relative path incorrectly requests resource from local
origin needlessly
https://bugs.webkit.org/show_bug.cgi?id=269635
rdar://123545197
Reviewed by Chris Dumez.
When an HTTP response for a subresource carries a `Link` header (e.g.
`Link: </a.js>; rel=modulepreload`), SubresourceLoader passed the document's
URL as the base for resolving the link target. This is wrong: per RFC 8288
Section 3.2 [1], the context of a link conveyed in the Link header field is, by
default, the URL of the representation it is associated with -- i.e. the
subresource's own URL -- and a base URI from the document's content is
explicitly not applied. RFC 3986 Section 5.1.3 [2] further defines that
retrieval URL as the base, and specifies that after a redirect the last URI
used (the one that actually retrieved the representation) is the base.
For a same-origin subresource the two bases coincide, so the bug was invisible.
But when the subresource is cross-origin (e.g. a module imported from a CDN, or
a jsDelivr `+esm` bundle), the preload was issued against the document's (local)
origin instead of the subresource's origin. This produced a needless, erroneous
request to the document's origin (typically a 404), followed by a "preloaded but
not used" console warning, since the real load went to the correct origin via
the normal module/resource resolution path.
Resolve subresource `Link` headers against the response URL, which is the
representation's retrieval URL and correctly reflects any redirect, instead of
the document URL.
[1] https://datatracker.ietf.org/doc/html/rfc8288#section-3.2
[2] https://datatracker.ietf.org/doc/html/rfc3986#section-5
Test:
imported/w3c/web-platform-tests/preload/cross-origin-link-header-on-subresource.sub.html
*
LayoutTests/imported/w3c/web-platform-tests/preload/cross-origin-link-header-on-subresource.sub-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/preload/cross-origin-link-header-on-subresource.sub.html:
Added.
* LayoutTests/http/tests/preload/link-header-on-subresource.html: Resolve the
preloaded path against the subresource, matching the corrected base URL.
* LayoutTests/http/tests/preload/resources/dummy.js: Added. Preload target at
the subresource-relative location.
* Source/WebCore/loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::didReceiveResponse):
Canonical link: https://commits.webkit.org/315577@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
