1582503 - [wpt-sync] Sync PR 19164 - Re-land: Fix `Referer` for descendant module scripts and worklets

Status: RESOLVED INVALID

(Testing :: web-platform-tests, task, P4)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Sync web-platform-tests PR 19164 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/19164
Details from upstream follow.

Dominic Farolino <[e-mail]> wrote:

Re-land: Fix Referer for descendant module scripts and worklets

This CL is a re-land of https://crrev.com/c/1786260, which was reverted
due to an increased number of cancelled requests, because requests with
null initiator origins were treated as cross-origin when generating the
referrer string. Parts of Chrome beyond the web platform (e.g., file
downloads) relied on these requests being treated as same-origin. We
reverted the CL to unblock the Dev build release, and this CL is a
re-land with fixes: it preserves the old behavior for requests that have
null initiators (i.e., these are considered same-origin with their
referrer), but corrects the behavior for requests with non-null initiators
(i.e., the initiator origin is used to determine same-origin-ness). The
original patch description is below:

This CL addresses a problem with SecurityPolicy::GenerateReferrer
when it comes to checking the same-origin-ness of a request. The
WebAppSec Referrer Policy Standard defines a same-origin request 1 as
one where the request's origin and current URL are same-origin with
each other. This comparison is done in "determine a request's referrer"
algorithm.

The analogous place in our implementation is
SecurityPolicy::GenerateReferrer. Before this CL, GenerateReferrer would
determine a request's same-origin-ness by comparing the origin of the
request's referrer string and the origin of the request's current URL.
Most of the time this was sufficient, as the request's referrer string
is almost always same-origin with the request's origin (initiator
in Blink). With descendant module scripts and worklets however, the
origin of the request's referrer string and request's origin (initiator)
could be different, which breaks the correctness of our GenerateReferrer
method.

This CL introduces a blink::SecurityOrigin parameter to the
GenerateReferrer method, so that correct same-origin comparisons can be
carried out. In all GenerateReferrer call-sites, an appropriate origin
is passed in.

The original CL 2 was reverted because the semantics of
SecurityPolicy::GenerateReferrer were not kept in sync with the similar
logic in net::URLRequestJob::ComputeReferrerForPolicy, which caused a
DumpWithoutCrashing bug seen in https://crbug.com/1000614, and request
cancellations. This reland updates the ComputeReferrerForPolicy logic
to match the corresponding Blink logic, and includes documentation
mentioning that changes to one section should be reflected in the other.
This CL also includes web platform tests for the scenario in the
aforementioned bug, which pass with this CL, as well as net unit tests
for RedirectInfo and URLRequestJob.

TBR=[e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]

Bug: 786862
Change-Id: Ic49d17bb8db923edb99d9ee952a18b0355cdb115
Reviewed-on: https://chromium-review.googlesource.com/1808663
WPT-Export-Revision: d5e161010b0ffc8e778dd19d701caf031061650d