navigation: Preserve HTTP cache partition across main-frame reloads [chromium/src : main]
Helmut Januschka (Gerrit)
Helmut Januschka added 1 comment![]( "Open in Gerrit")
Charlie Reishi @cr...@chromium.org, it was suggested I ask for your navigation expertise on this one. The root cause is that an opaque-initiator PWA launch uses the `cn_` HTTP cache partition, while `location.reload()` uses the regular partition, leaving future cold launches on stale `cn_` content. PS14 preserves the original cache classification across reloads, but that is a broad change with security implications, so guidance on whether reloads should retain that classification at all would be greatly appreciated. thank you!
Helmut JanuschkaApologies for the delay; I've got a lot in my queue right now.
I appreciate the brief summary, but I'm having trouble fitting together these pieces. Can you update the CL description a bit more to explain the current understanding of the problem and how this is fixing it?
Between this summary and a quick skim of the bug, my best guess is that it's related to partitioning the HTTP cache (https://crbug.com/347934841)? It sounds like that partitioning is based on initiator origins, but maybe PWAs have a special case where an opaque initiator origin is used, but not if you do a renderer-initiated reload, so we end up using different cache partitions for those cases?
I'm hesitant to add new NavigationEntry state that might need persisting, but I want to make sure I understand what problem is being solved first, and whether it affects other scenarios (e.g., with other types of opaque initiator origins) as well. Thanks!
Thanks for taking a look! update commit msg, sorry missed that, had like a few plot twists.
The mechanism: since crbug.com/347934841, main-frame navigation cache keys get a "cn_" prefix when the request initiator is cross-site to the destination, and opaque initiators always count as cross-site.
Android PWA/WebAPK launches navigate with an opaque initiator (crrev.com/c/3966130), so every cold launch reads/writes the "cn_" partition.
location.reload() is renderer-initiated with the document's own origin, which is same-site, so the fresh response lands in the unprefixed partition and future launches keep serving the stale "cn_" entry; it never self-heals.
It isn't PWA-specific: any cross-site-initiated navigation (link from another site, other opaque initiators) followed by a reload has the same partition flip, which is why the added browser test uses a plain cross-site navigation with no PWA involved.
On the NavigationEntry state: it's intentionally not persisted (similar to isolation_info_).
If it's missing, e.g. after session restore, the reload falls back to the frame entry's initiator, i.e. today's behavior, so the worst case is one cache miss. The reason it can't be derived from the FrameNavigationEntry's initiator_origin alone is that each commit updates that field, so after the first reload the original classification would be lost for subsequent reloads.
The design question I'd appreciate your take on, should a reload retain the original navigation's cache classification at all (as PS14 does), or would you prefer fixing the mismatch elsewhere?
Happy to rework if you see a cleaner point.
again thank you, and dont worry about delay's!
Related details
- Charlie Reis
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Charlie Reis (Gerrit)
Charlie Reis added 1 comment![]( "Open in Gerrit")
Charlie Reishi @cr...@chromium.org, it was suggested I ask for your navigation expertise on this one. The root cause is that an opaque-initiator PWA launch uses the `cn_` HTTP cache partition, while `location.reload()` uses the regular partition, leaving future cold launches on stale `cn_` content. PS14 preserves the original cache classification across reloads, but that is a broad change with security implications, so guidance on whether reloads should retain that classification at all would be greatly appreciated. thank you!
Helmut JanuschkaApologies for the delay; I've got a lot in my queue right now.
I appreciate the brief summary, but I'm having trouble fitting together these pieces. Can you update the CL description a bit more to explain the current understanding of the problem and how this is fixing it?
Between this summary and a quick skim of the bug, my best guess is that it's related to partitioning the HTTP cache (https://crbug.com/347934841)? It sounds like that partitioning is based on initiator origins, but maybe PWAs have a special case where an opaque initiator origin is used, but not if you do a renderer-initiated reload, so we end up using different cache partitions for those cases?
I'm hesitant to add new NavigationEntry state that might need persisting, but I want to make sure I understand what problem is being solved first, and whether it affects other scenarios (e.g., with other types of opaque initiator origins) as well. Thanks!
Thanks for taking a look! update commit msg, sorry missed that, had like a few plot twists.
The mechanism: since crbug.com/347934841, main-frame navigation cache keys get a "cn_" prefix when the request initiator is cross-site to the destination, and opaque initiators always count as cross-site.
Android PWA/WebAPK launches navigate with an opaque initiator (crrev.com/c/3966130), so every cold launch reads/writes the "cn_" partition.location.reload() is renderer-initiated with the document's own origin, which is same-site, so the fresh response lands in the unprefixed partition and future launches keep serving the stale "cn_" entry; it never self-heals.
It isn't PWA-specific: any cross-site-initiated navigation (link from another site, other opaque initiators) followed by a reload has the same partition flip, which is why the added browser test uses a plain cross-site navigation with no PWA involved.
On the NavigationEntry state: it's intentionally not persisted (similar to isolation_info_).
If it's missing, e.g. after session restore, the reload falls back to the frame entry's initiator, i.e. today's behavior, so the worst case is one cache miss. The reason it can't be derived from the FrameNavigationEntry's initiator_origin alone is that each commit updates that field, so after the first reload the original classification would be lost for subsequent reloads.
The design question I'd appreciate your take on, should a reload retain the original navigation's cache classification at all (as PS14 does), or would you prefer fixing the mismatch elsewhere?
Happy to rework if you see a cleaner point.
again thank you, and dont worry about delay's!
Thanks for the explanation! This does sound like a deeper design level concern with the partitioned HTTP cache, with a fundamental question about how reloads after any cross-site navigation should be treated.
awillia@: Was this discussed at all during the design of that feature? Do you have thoughts on how it should behave?
It does seem tricky to tie the cache to an initiator origin if subsequent same-origin navigations (including reloads) will then switch to a different cache.
Related details
- Andrew Williams
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |