Consider redirects when defining same-site

[englehardt]

Addresses #889.

Note that this change also simplifies the definition by referencing the fetch definition of when two origins are considered same-site. The text is the current version is effectively a copy-paste of that definition.

[englehardt]

PTAL @chlily1 @miketaylr @annevk

[chlily1]

Thanks, this LGTM!

[reschke]

That seems very misleading to me. If you add a date, you'll also need a URI that point to that very version.

[miketaylr]

If you add a date, you'll also need a URI that point to that very version.

You can grab a snapshot using this fancy button:

[englehardt]

If you add a date, you'll also need a URI that point to that very version.

You can grab a snapshot using this fancy button:

I looked a bit more at the process here, and linking to a permalink in a spec is discouraged by HTML. See https://whatwg.org/working-mode#anchors. Specifically However, other standards organizations are discouraged from referencing these snapshots, as they generally contain contain known issues that have been fixed in the Living Standard, and can mislead implementers and web developers..

Following that process: I've filed whatwg/html#6329, and will reference that anchor using a non-snapshot link & date as a separate reference from the rest of these HTML terms the spec already references.

[miketaylr]

@englehardt it would be good to also add a changelog entry here.

[englehardt]

@chlily1 Would you mind taking another look at this post-merge with #1384? I've simplified the language in the same-site section regarding how we calculate same-site for requests which are reload navigations resulting from UI. Previously you had:

whether that request is same-site or cross-site should be evaluated based on the client of the request that originally navigated to the reloaded page, rather than the client of the request itself.

But consider the example of a user that types in B.com in the address bar (i.e., no client), B.com HTTP redirects to A.com, and then the user manually refreshes A.com. The B.com to A.com redirect makes the initial load cross-site, and thus we'd expect the user-initiated reload to still be cross-site. But if we followed the quoted text above, we'd use the client of the initial load (i.e., null) and conclude the new request should be same-site. I've instead opted to use the criteria you added later in the draft:

Requests which are the result of a reload navigation triggered through a user interface element are same-site if the reloaded document was originally navigated to via a same-site request.

[englehardt]

I've also made a terminology change, moving from target's URI's origin to request's current url's origin for the third criteria. This aligns with what I've added in the first criteria, and actually the original term target was never defined in the draft and isn't used elsewhere.

[chlily1]

@chlily1 Would you mind taking another look at this post-merge with #1384? I've simplified the language in the same-site section regarding how we calculate same-site for requests which are reload navigations resulting from UI. Previously you had:

whether that request is same-site or cross-site should be evaluated based on the client of the request that originally navigated to the reloaded page, rather than the client of the request itself.

But consider the example of a user that types in B.com in the address bar (i.e., no client), B.com HTTP redirects to A.com, and then the user manually refreshes A.com. The B.com to A.com redirect makes the initial load cross-site, and thus we'd expect the user-initiated reload to still be cross-site. But if we followed the quoted text above, we'd use the client of the initial load (i.e., null) and conclude the new request should be same-site. I've instead opted to use the criteria you added later in the draft:

Requests which are the result of a reload navigation triggered through a user interface element are same-site if the reloaded document was originally navigated to via a same-site request.

Nice catch, thanks! Lgtm.