referer / referrer during reloads & history entry repopulations #6813

jakearchibald · 2021-06-29T14:44:30Z

History entry repopulations: When you traverse to a history entry that doesn't have a document, so it needs refetching.

I've been testing using https://redirect-session-history.glitch.me, and it seems like, when reloading a page or traversing back to a page, browsers will send the same referer that was originally used for the first fetch of the page.

That includes cases like:

Page //origin-1/a
Navigate to page //origin-1/b (so referrer is //origin-1/a)
Reload, which redirects to //origin-1/c

//origin-1/c will have a referrer of //origin-1/a.

One minor browser difference:

Page //origin-1/a
Navigate to page //origin-1/b (so referrer is //origin-1/a)
Reload, which redirects to //totally-different-origin/foo, which redirects back to //origin-1/c

In this case Chrome and Firefox simplify the referrer to //origin-1/ (with the full origin of course), whereas Safari uses the full referrer //origin-1/a.

My plan is to spec the Chrome & Firefox behaviour by storing the referrer along with the "document state". The document state is the state needed to recreate a document, and is shared between multiple session history entries (entries that will share a document).

The text was updated successfully, but these errors were encountered:

jakearchibald · 2021-06-29T14:48:22Z

Btw, let me know if this stuff is spec'd and I just can't find it. I followed the spec for reload() and it seems like the referrer just ends up as "client", meaning the referrer would be itself, which isn't what browsers do.

domenic · 2021-06-29T15:45:02Z

I wonder how referrer policy plays into this... usually its drawn from the fetch client. So imagine something like

//origin-1/a with referrer policy "unsafe-url"
//origin-1/b
//origin-1/c with referrer policy "no-referrer"

When navigating from 1 -> 2 the referrer would be //origin-1/a, the full URL. Then we navigate to 3. What if we click the back button then (with no bfcache)? Should the referrer be missing, based on 3's referrer policy? Or should it be //origin-1/a, the original referrer? If the latter, how do we thread that through specs?

domenic · 2021-06-29T21:13:04Z

If the latter, how do we thread that through specs?

I guess we could just set the referrer explicitly and then set the referrer policy to the empty string. Not so bad.

jakearchibald · 2021-06-30T08:06:22Z

Yeah, right now I'm allowing the referrer to be a URL or "no-referrer", which are used by fetch.

jakearchibald · 2021-06-30T14:13:34Z

Referrer policy is stored in the history entry too. Test:

Page //origin-1/a.
Navigate to page //origin-1/b using a link with referrerpolicy="same-origin" (so referrer is //origin-1/a).
Reload, which redirects to //totally-different-origin/foo.

Firefox and Chrome will omit Referer. Safari will send the full referrer //origin-1/a.

I'm going continue speccing the Chrome & Firefox behaviour.

annevk · 2021-07-21T12:10:35Z

See also w3c/webappsec-fetch-metadata#71.

domenic · 2021-08-06T19:03:16Z

It turns out Chromium and WebKit distinguish between user-triggered reloads and other reloads. Test case:

Go to https://example.com/
Click the "more information" link taking you to https://www.iana.org/domains/reserved
Open your console and type document.referrer. You get https://example.com/
Press the reload button on your browser
Open your console and type document.referrer. You get https://example.com/
In the same console, type location.reload().
Open your console and type document.referrer. You get:
- https://example.com/ in Firefox
- https://www.iana.org/domains/reserved in Chromium, due to this code
- https://www.iana.org/domains/reserved in WebKit

domenic · 2022-10-10T10:45:18Z

@domfarolino is working on some tests for this in web-platform-tests/wpt#36352 . However it's for the repopulation case, not the reload case.

This CL is a follow-up to https://crrev.com/c/3936785 and whatwg/html#6813 (comment). It adds a test asserting the document state preservation as described more below, in the `location.reload()` case, alongside a very similar test that asserts the same for the document repopulation case. The HTML Standard specifies the behavior of `location.reload()` to preserve the existing history entry's document state's initiator origin and referrer, as described in: https://html.spec.whatwg.org/multipage/browsing-the-web.html#apply-the-history-step:~:text=If%20targetEntry%27s%20document%20is%20null%2C%20or%20targetEntry%27s%20document%20state%27s%20reload%20pending%20is%20true%2C%20then. This means that when a page is navigated to from a cross-origin predecessor, and then `location.reload()`s itself, `Sec-Fetch-Site` should be `cross-site` and the `Referer` header should remain the same as the original navigation. Chromium currently fails this test, per whatwg/html#6813 (comment) and the code pointer described by that comment. [email protected] Bug: N/A Change-Id: I868ac9fad7e63df251d6c4b0d0ac8b099b81d25b

This CL is a follow-up to https://crrev.com/c/3936785 and whatwg/html#6813 (comment). It adds a test asserting the document state preservation as described more below, in the `location.reload()` case, alongside a very similar test that asserts the same for the document repopulation case. The HTML Standard specifies the behavior of `location.reload()` to preserve the existing history entry's document state's initiator origin and referrer, as described in: https://html.spec.whatwg.org/multipage/browsing-the-web.html#apply-the-history-step:~:text=If%20targetEntry%27s%20document%20is%20null%2C%20or%20targetEntry%27s%20document%20state%27s%20reload%20pending%20is%20true%2C%20then. This means that when a page is navigated to from a cross-origin predecessor, and then `location.reload()`s itself, `Sec-Fetch-Site` should be `cross-site` and the `Referer` header should remain the same as the original navigation. Chromium currently fails this test, per whatwg/html#6813 (comment) and the code pointer described by that comment. [email protected] Bug: N/A Change-Id: I868ac9fad7e63df251d6c4b0d0ac8b099b81d25b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4504799 Commit-Queue: Domenic Denicola <[email protected]> Auto-Submit: Dominic Farolino <[email protected]> Reviewed-by: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1145759}

…t, a=testonly Automatic update from web-platform-tests Add location.reload() document state test This CL is a follow-up to https://crrev.com/c/3936785 and whatwg/html#6813 (comment). It adds a test asserting the document state preservation as described more below, in the `location.reload()` case, alongside a very similar test that asserts the same for the document repopulation case. The HTML Standard specifies the behavior of `location.reload()` to preserve the existing history entry's document state's initiator origin and referrer, as described in: https://html.spec.whatwg.org/multipage/browsing-the-web.html#apply-the-history-step:~:text=If%20targetEntry%27s%20document%20is%20null%2C%20or%20targetEntry%27s%20document%20state%27s%20reload%20pending%20is%20true%2C%20then. This means that when a page is navigated to from a cross-origin predecessor, and then `location.reload()`s itself, `Sec-Fetch-Site` should be `cross-site` and the `Referer` header should remain the same as the original navigation. Chromium currently fails this test, per whatwg/html#6813 (comment) and the code pointer described by that comment. [email protected] Bug: N/A Change-Id: I868ac9fad7e63df251d6c4b0d0ac8b099b81d25b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4504799 Commit-Queue: Domenic Denicola <[email protected]> Auto-Submit: Dominic Farolino <[email protected]> Reviewed-by: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1145759} -- wpt-commits: d9c2152bab4d2933e38c8df3c95d967c40809f8c wpt-pr: 39878

…t, a=testonly Automatic update from web-platform-tests Add location.reload() document state test This CL is a follow-up to https://crrev.com/c/3936785 and whatwg/html#6813 (comment). It adds a test asserting the document state preservation as described more below, in the `location.reload()` case, alongside a very similar test that asserts the same for the document repopulation case. The HTML Standard specifies the behavior of `location.reload()` to preserve the existing history entry's document state's initiator origin and referrer, as described in: https://html.spec.whatwg.org/multipage/browsing-the-web.html#apply-the-history-step:~:text=If%20targetEntry%27s%20document%20is%20null%2C%20or%20targetEntry%27s%20document%20state%27s%20reload%20pending%20is%20true%2C%20then. This means that when a page is navigated to from a cross-origin predecessor, and then `location.reload()`s itself, `Sec-Fetch-Site` should be `cross-site` and the `Referer` header should remain the same as the original navigation. Chromium currently fails this test, per whatwg/html#6813 (comment) and the code pointer described by that comment. R=domenicchromium.org Bug: N/A Change-Id: I868ac9fad7e63df251d6c4b0d0ac8b099b81d25b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4504799 Commit-Queue: Domenic Denicola <domenicchromium.org> Auto-Submit: Dominic Farolino <domchromium.org> Reviewed-by: Domenic Denicola <domenicchromium.org> Cr-Commit-Position: refs/heads/main{#1145759} -- wpt-commits: d9c2152bab4d2933e38c8df3c95d967c40809f8c wpt-pr: 39878 UltraBlame original commit: 2342752e35cc28fc870b3576d5d7a22b9f92e7fd

jakearchibald added the topic: history label Jun 29, 2021

domenic added the interop Implementations are not interoperable with each other label Aug 6, 2021

domenic mentioned this issue Mar 4, 2022

Navigation and session history rewrite #6315

Merged

8 tasks

domenic closed this as completed in 0a97a81 Oct 31, 2022

domenic closed this as completed in #6315 Oct 31, 2022

domfarolino mentioned this issue Nov 25, 2022

User-triggered reloads get a different referrer than browser-triggered ones #6938

Closed

chromium-wpt-export-bot mentioned this issue May 6, 2023

Add location.reload() document state test web-platform-tests/wpt#39878

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

referer / referrer during reloads & history entry repopulations #6813

referer / referrer during reloads & history entry repopulations #6813

jakearchibald commented Jun 29, 2021 •

edited

Loading

jakearchibald commented Jun 29, 2021 •

edited

Loading

domenic commented Jun 29, 2021

domenic commented Jun 29, 2021

jakearchibald commented Jun 30, 2021

jakearchibald commented Jun 30, 2021

annevk commented Jul 21, 2021

domenic commented Aug 6, 2021

domenic commented Oct 10, 2022

referer / referrer during reloads & history entry repopulations #6813

referer / referrer during reloads & history entry repopulations #6813

Comments

jakearchibald commented Jun 29, 2021 • edited Loading

jakearchibald commented Jun 29, 2021 • edited Loading

domenic commented Jun 29, 2021

domenic commented Jun 29, 2021

jakearchibald commented Jun 30, 2021

jakearchibald commented Jun 30, 2021

annevk commented Jul 21, 2021

domenic commented Aug 6, 2021

domenic commented Oct 10, 2022

jakearchibald commented Jun 29, 2021 •

edited

Loading

jakearchibald commented Jun 29, 2021 •

edited

Loading