Consider splitting document into document and nested-document.
#755
Comments
|
Since Request.destination was only relatively recently shipped in browsers, now might be the time to make this change. Sites would need to adapt, but they could do FWIW, this better matches what firefox uses internally: Which we then map to the exposed I was wondering if this change would interact badly with the portals proposal, but I guess the navigation request would have to complete well before any portal is promoted from 3rd party to 1st party. |
|
Thanks, @wanderview, that's helpful. Who should we loop in from WebKit/Edge to see if they'd be willing to do the same? |
|
I am not totally clear about the intent of this change. FWIW, WebKit has this is-top-level-navigation concept, although at a slightly lower level. The proposed change seems ok from that prospective. |
|
Hey, @youennf!
Right now,
That's also a distinction that I think might be useful, but it's not my intent. Offering that capability to developers would be a happy side-effect of this change. :) |
|
That seems reasonable to me. Given a service worker might expose the same data that servers would provide directly, it makes sense to me that a service worker should get the same level of information as the one provided to the server through Sec-Metadata, at least for navigation loads. |
|
Isn't this information (and more) already available by getting the client associated with |
|
Do you mean Also, I don't think |
|
The idea of exposing the header to service workers sounds interesting. My initial thought is what'd be a downside of maintaining the target member? The values of the destination look more like what the request's resulting resource kind would be. If we split them, there seems to be quite a few places that need some clarification. E.g. "A navigation request is a request whose destination is "document" or "nested-document", etc.
Yes. |
|
@wanderview wouldn't |
I think we answered this on IRC. Since targetClientId will be null for cross-origin targets or new top level windows it can't really be used reliably to determine the type of request. |
|
@arturjanc reminded me that I never came back to this. Do y'all think it's worth trying to poke at |
|
I'd prefer changing |
|
I put up #819. I'll find time to put up an HTML counterpart. |
|
In w3c/webappsec-fetch-metadata#16, @annevk suggested that we move this to the request's |
|
When discussing the definition of Prefetch's processing model it was raised that we probably want to limit it in some cases to top-level navigations. In that context, a |
|
Would a |
|
It will require us to rewire some |
|
I don't have strong opinions either way. As long as I can distinguish nested vs. non-nested navigations in some way, I'm happy. We could even do both. Whatever. :) |
|
OK, I read the thread on the issue, and IIUC there's still an open question there on whether we want to expose If it is exposed, I think it'd be cleaner to have nestedness be part of |
|
If it ends up not being exposed, and "nested-navigate" |
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <kinukochromium.org>
Reviewed-by: Łukasz Anforowicz <lukaszachromium.org>
Commit-Queue: Mike West <mkwstchromium.org>
Cr-Commit-Position: refs/heads/master{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
UltraBlame original commit: 7d3b0c03f936cc0fb5a532f740664b0517ec0cc9
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <kinukochromium.org>
Reviewed-by: Łukasz Anforowicz <lukaszachromium.org>
Commit-Queue: Mike West <mkwstchromium.org>
Cr-Commit-Position: refs/heads/master{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
UltraBlame original commit: 7d3b0c03f936cc0fb5a532f740664b0517ec0cc9
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <kinukochromium.org>
Reviewed-by: Łukasz Anforowicz <lukaszachromium.org>
Commit-Queue: Mike West <mkwstchromium.org>
Cr-Commit-Position: refs/heads/master{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
UltraBlame original commit: 7d3b0c03f936cc0fb5a532f740664b0517ec0cc9
|
This was fixed by #948. |
As discussed in the context of
Sec-Metadata, it might be useful to clearly distinguish between top-level and nested navigation requests by splitting thedocumentdestination intodocumentandnested-document.@annevk notes that this might be a breaking change, as folks might be relying on the existing
documentdestination that's exposed onRequestobjects. @wanderview, @jakearchibald: WDYT?The text was updated successfully, but these errors were encountered: