Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable
3,521 views
Skip to first unread message
Daniel Vogelheim
Oct 27, 2022, 9:49:44 AM10/27/22
to blink-dev, Yoav Weiss
Hello all,
The approval for the Intent To Ship for Origin Isolation By Default / Deprecate document.domain asks for a separate intent for the actual default change. This is that separate intent.
A summary of what happened so far:
- Shipping Origin Isolation by Default (and thereby deprecating document.domain) has security benefits, but compatibility risk.
- We added warnings to the developer console and issues panel, published a blog post, and engaged in direct outreach. This has resulted in substantial, measurable reduction of usage. Some sites keep using document.domain, but have mitigated the deprecation with other means. This makes the risk difficult to measure.
- Sampling of sites with document.domain usage and manual inspection yields a potential breakage estimate at ~0.015% of page views.
What we're asking for here is:
- Enable the feature at 50% for beta (+ dev + canary) during M109, as a "last call" for web site authors.
- Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
------------------------
Contact emails
[email protected], [email protected]
Specification
Explainer: https://github.com/mikewest/deprecating-document-domain
HTML Spec draft: https://github.com/whatwg/html/compare/main...otherdaniel:dd
API spec
Yes
Summary
This is a follow-on to the Intent to Ship: Origin Isolation By Default / Deprecate document.domain. We'd like to ship this in M110, stable.
Summary (of the underlying change)
Change the default behavior of the Origin-Agent-Cluster: header / document.domain settability.
Presently, pages within Chromium have site-keyed agent clusters by default, unless the Origin-Agent-Cluster: header is explicitly set to true. This accommodates pages or frames which want to access each other's state, despite being on different origins (but within a site). This is fine for any pages that wish to do so, but because a page *might* set document.domain later on, Chromium currently must use site-keyed agent clusters for *all* pages by default even though the overwhelming majority of pages do not ever make use of this (mis-)feature. In turn, this requires Chromium to use sites as the basis for renderer process isolation (via Site Isolation), which exposes origins to same-site but cross-origin attacks involving compromised renderer processes or the "Spectre" family of side-channel attacks.
This proposal changes the default behaviour of Origin-Agent-Cluster. From a developer's point of view, the new default matches "Origin-Agent-Cluster: ?1". The initial implementation will use origin-keyed agent clusters for all (non-opted out) origins, without changing how many processes Chromium creates. Over time, we can then adapt Chromium's isolation strategy towards origin-keyed processes without further affecting web-visible behaviour.
The developer-visible aspect of this is that for pages with origin-keyed agent clusters, document.domain is no longer settable. Thus, we have marked this intent as a deprecation.
Note that this proposal is about the default. Both modes - site-keyed or origin-keyed agent clusters - remain available to any site, but origin-keyed agent clusters change from opt-in to opt-out. The current behaviour remains available by setting "Origin-Agent-Cluster: ?0".
Blink component
Blink>SecurityFeature
TAG review
https://github.com/w3ctag/design-reviews/issues/564
Risks: Interoperability and Compatibility
There are compatibility risks, which we have reduced with outreach and warnings, and we want to mitigate further by launching at 50% of beta first. An extended discussion of the risk (including attempts at quantitative assessment) can be found in the original intent to ship.
Gecko: Standards position request. ("Worth prototyping")
WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html (No signals.)
Web developers: No signals.
Activation - Deprecation plan
M109: Enable "Origin Agent Cluster by Default" for 50% of page loads on beta, dev, and canary.
M110: Enable "Origin Agent Cluster by Default" on stable.
Security
This change should be security-positive, since setting document.domain will not have any impact on the origin of the document any more.
Debuggability
A deprecation warning has been added to DevTools console and to the issues panel in M98. This warning will file a deprecation report as well using the Reporting API, if so configured.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
This is covered by Origin-keyed Agent Cluster tests.
Tracking bug
https://crbug.com/1139851
Launch bug
https://crbug.com/1246823
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5428079583297536 (document.domain setter deprecation)
https://chromestatus.com/features/5683766104162304 (Origin-keyed agent clusters)
Mike Taylor
Nov 9, 2022, 11:10:46 AM11/9/22
to Daniel Vogelheim, blink-dev, Yoav Weiss
On 10/27/22 11:49 PM, 'Daniel
Vogelheim' via blink-dev wrote:
Hello all,
The approval for the Intent To Ship for Origin Isolation By Default / Deprecate document.domain asks for a separate intent for the actual default change. This is that separate intent.
A summary of what happened so far:
- Shipping Origin Isolation by Default (and thereby deprecating document.domain) has security benefits, but compatibility risk.
- We added warnings to the developer console and issues panel, published a blog post, and engaged in direct outreach. This has resulted in substantial, measurable reduction of usage. Some sites keep using document.domain, but have mitigated the deprecation with other means. This makes the risk difficult to measure.
- Sampling of sites with document.domain usage and manual inspection yields a potential breakage estimate at ~0.015% of page views.
What we're asking for here is:
- Enable the feature at 50% for beta (+ dev + canary) during M109, as a "last call" for web site authors.
This sounds like a good idea. Is there any reason we couldn't go to 50% in M108 as well (or are you trying to avoid breakage over the winter holidays)?
Another question: do we have enterprise policies available for
this change?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNEMgvrOehp5%2Bf48yQ62pY3xqXqATPNxWZ6aYQ%2BXeHHAg%40mail.gmail.com.
Daniel Vogelheim
Nov 9, 2022, 12:05:59 PM11/9/22
to Mike Taylor, blink-dev, Yoav Weiss
On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor <[email protected]> wrote:
On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
Hello all,
The approval for the Intent To Ship for Origin Isolation By Default / Deprecate document.domain asks for a separate intent for the actual default change. This is that separate intent.
A summary of what happened so far:
- Shipping Origin Isolation by Default (and thereby deprecating document.domain) has security benefits, but compatibility risk.
- We added warnings to the developer console and issues panel, published a blog post, and engaged in direct outreach. This has resulted in substantial, measurable reduction of usage. Some sites keep using document.domain, but have mitigated the deprecation with other means. This makes the risk difficult to measure.
- Sampling of sites with document.domain usage and manual inspection yields a potential breakage estimate at ~0.015% of page views.
What we're asking for here is:
- Enable the feature at 50% for beta (+ dev + canary) during M109, as a "last call" for web site authors.
This sounds like a good idea. Is there any reason we couldn't go to 50% in M108 as well (or are you trying to avoid breakage over the winter holidays)?
No reason. I'd be happy to go to beta as soon as I receive the lgtms. I had conservatively budgeted that to be 109. :-)
Another question: do we have enterprise policies available for this change?
Yes; the policy is here: OriginAgentClusterDefaultEnabled
Yoav Weiss
Nov 10, 2022, 6:19:45 AM11/10/22
to Daniel Vogelheim, Mike Taylor, blink-dev
LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or M109, and carefully roll this out for M110, once it hits stable.
Chris Harrelson
Nov 10, 2022, 10:19:04 AM11/10/22
to Yoav Weiss, Daniel Vogelheim, Mike Taylor, blink-dev
LGTM2
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0vt%2BzXxGf_f7YBF2Lq1K1y5F_VJMtK6whuSiQX9_t3g%40mail.gmail.com.
Mike Taylor
Nov 10, 2022, 10:42:37 AM11/10/22
to Chris Harrelson, Yoav Weiss, Daniel Vogelheim, blink-dev
LGTM3
Yaseen Khan
Dec 5, 2022, 10:02:52 AM12/5/22
to blink-dev, Daniel Vogelheim, [email protected]
Hi Daniel,
Need clarifications for the below points.
Activation - Deprecation plan
M109: Enable "Origin Agent Cluster by Default" for 50% of page loads on beta, dev, and canary.--- As a developer, do I need to set
"Origin-Agent-Cluster: ?1" as a header for 50% of page visits or chromium enforcing for 50% of page visits from browser(Means 50% ( "Origin-Agent-Cluster: ?1") and another 50% ( "Origin-Agent-Cluster: ?0")?.
I have installed M109 beta and I have not set orginAgentCluster in my site and I can see in console "window.originAgentCluster" always return false for all sites/pages. Could you clarify on this?. How do I know whether Origin-Agent-Cluster enabled or not in M109?
Daniel Vogelheim
Dec 14, 2022, 11:36:56 AM12/14/22
to Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev
Hello all,
An update: Unfortunately we have discovered a bug with this feature, just as I was getting ready to enable it. The bug also affects pages that have not even set document.domain. Since I have now missed a substantial portion of the 109 beta cycle I'd like to delay the roll out once more, and shift it by one milestone (or two; depending on when everything is fixed).
On the positive side: Recently the last of the previously identified big document.domain users, that together accounted for about 50% of remaining usage, has dropped their usage. So current usage is lower than previously reported. See the usage dip around late November at deprecate.it (1st graph).
Daniel Vogelheim
Dec 14, 2022, 11:47:52 AM12/14/22
to Yaseen Khan, blink-dev, [email protected]
Hello Yaseen,
Sorry for not betting back earlier.
On Mon, Dec 5, 2022 at 10:05 AM Yaseen Khan <[email protected]> wrote:
Activation - Deprecation plan
M109: Enable "Origin Agent Cluster by Default" for 50% of page loads on beta, dev, and canary.--- As a developer, do I need to set "Origin-Agent-Cluster: ?1" as a header for 50% of page visits or chromium enforcing for 50% of page visits from browser(Means 50% ( "Origin-Agent-Cluster: ?1") and another 50% ( "Origin-Agent-Cluster: ?0")?.
No, you should always set the header (or remove document.domain usage). Setting the header means you instruct the browser to cluster pages by origin ("?1") (or not, "?0"), and thus the change of the default will not affect you, since you're no longer relying on the default.
Note that origin-agent clustering has been implemented for quite a while. What changes now is how the default is handled: Pages that do not explicitly request clustering to be on or off used to get the off behaviour ("?0"), and will soon get the on behaviour ("?1"). In other words, it turns from an opt-in feature into an opt-out feature. By setting the header to off ("?0"), you request "off" behaviour - which in the past you got automatically. It's safe to always do that, since it retains current behaviour.
I have installed M109 beta and I have not set orginAgentCluster in my site and I can see in console "window.originAgentCluster" always return false for all sites/pages. Could you clarify on this?. How do I know whether Origin-Agent-Cluster enabled or not in M109?
M109 beta: Your observation is correct. Because of a bug found at the last minute, I have not actually enabled the feature. Unfortunately I have to delay the rollout.
Daniel Vogelheim
Jan 13, 2023, 8:53:57 AM1/13/23
to Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev
Hello all,
We've now handled the bugs we've discovered, and I would like to make another attempt at launching. I'll follow the plan that was approved here, but two milestones later: Launch to 50% beta in M111 (or late M110, if I can still catch a bit of that release cycle), and then ramp on stable once M112 is out.
Rick Byers
Jan 13, 2023, 10:37:15 AM1/13/23
to Daniel Vogelheim, Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev, Eiji Kitamura, Brandon Heenan
Thanks for the update Daniel, good luck!
In case others, like me, have missed or forgotten the long history of this difficult deprecation and what it means for web developers, this blog post is a good summary. One critical thing it doesn't mention, but probably should, is that the OriginAgentClusterDefaultEnabled enterprise policy can also be used to revert the default on managed devices (though it looks like the launching milestone needs to be updated there too).
Rick
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPFMpseckt22K5bd%2BRsctwWihiwCdSA9vvCTZw_tOtT5A%40mail.gmail.com.
Eiji Kitamura
Jan 16, 2023, 2:06:05 AM1/16/23
to Rick Byers, Daniel Vogelheim, Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev, Brandon Heenan
I've updated the blog post stating Chrome 111 is where we ship the feature, but looks like it's rolling out through 111 and 112?
I'll update the blog post to mention `OriginAgentClusterDefaultEnabled` enterprise policy.
Rick Byers
Jan 16, 2023, 8:46:52 AM1/16/23
to Eiji Kitamura, Daniel Vogelheim, Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev, Brandon Heenan
Thanks so much Eiji!
Brandon Heenan
Jan 16, 2023, 10:21:33 AM1/16/23
to Rick Byers, Eiji Kitamura, Daniel Vogelheim, Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev, Marijke Hoste
We'll make the update in the enterprise release notes too. Thanks for keeping us in the loop
Eiji Kitamura
Jan 20, 2023, 10:12:32 AM1/20/23
to Brandon Heenan, Rick Byers, Daniel Vogelheim, Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev, Marijke Hoste
FYI, the enterprise bit has been added to the article.
Daniel Vogelheim
Mar 31, 2023, 8:54:21 AM3/31/23
to Eiji Kitamura, Brandon Heenan, Rick Byers, Mike Taylor, Chris Harrelson, Yoav Weiss, blink-dev, Marijke Hoste
Hello all, I'm afraid I have to delay this a bit more. :(
We have a bug report (tracked in crbug.com/1429587) that breaks existing apps. The important thing here is that it does not break document.domain setting and subsequent cross-origin access, but that instead -- if the conditions are just right; or arguably just wrong -- the app can get into a state where same-origin accesses are mistakenly blocked. Apparently an app can get into a state where frames within the same page are inconsistently assigned to agent clusters (i.e., frames in the same origin end up in different processes), and thus subsequent accesses within that origin may fail.
My plan right now is to leave this on at 50% beta, but to not proceed to any stable releases at any percentage. I'll update this thread when I have a better handle on the bug and can suggest a good way to proceed.
Mike Taylor
Mar 31, 2023, 9:17:32 AM3/31/23
to Daniel Vogelheim, Eiji Kitamura, Brandon Heenan, Rick Byers, Chris Harrelson, Yoav Weiss, blink-dev, Marijke Hoste
Thanks for the update Daniel, and good luck on fixing the bug. :)
Marijke Hoste
Apr 3, 2023, 12:01:54 PM4/3/23
to Mike Taylor, Daniel Vogelheim, Eiji Kitamura, Brandon Heenan, Rick Byers, Chris Harrelson, Yoav Weiss, blink-dev
Thanks for the update indeed!
On the Enterprise-side, we've mentioned this in the past 7 versions of the Enterprise Release Notes, so Admins are aware this is coming and have had sufficient notification. We don't think that it's necessary to update them of the (potential) delays.
 |
| ||||||
Eiji Kitamura
Apr 14, 2023, 12:05:29 AM4/14/23
to Marijke Hoste, Mike Taylor, Daniel Vogelheim, Brandon Heenan, Rick Byers, Chris Harrelson, Yoav Weiss, blink-dev
I've updated the blog so that it's clear that this change is not happening in Chrome 112.
Has the new milestone been determined yet?
Daniel Vogelheim
May 26, 2023, 9:25:07 AM5/26/23
to blink-dev, Brandon Heenan, Rick Byers, Mike Taylor, Chris Harrelson, Yoav Weiss, Eiji Kitamura, Marijke Hoste
Hello all, it's been a while... The bug reports should now be resolved, and we'd like to have another go at this in the M115 milestone. That is: Remain at 50% on beta; starting with 115 ramp up on stable to 1% / 10% / 50% / 100%, every 14d. Let's hope it sticks this time.
Daniel
Rick Byers
May 26, 2023, 10:21:08 AM5/26/23
to Daniel Vogelheim, blink-dev, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Eiji Kitamura, Marijke Hoste
Thanks for the update Daniel. Still LGTM. Good luck!
Eiji Kitamura
May 26, 2023, 10:25:52 AM5/26/23
to Rick Byers, Maud Nalpas, Daniel Vogelheim, blink-dev, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste
@Maud Nalpas is taking over the DevRel work.
Madanagopal Damodharan
Sep 7, 2023, 10:27:30 AM9/7/23
to blink-dev, Eiji Kitamura, Daniel Vogelheim, blink-dev, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
Hi All,
Is the feature launched in Chrome 115 as updated in https://developer.chrome.com/blog/document-domain-setter-deprecation? I have some of the customers reporting inconsistent behavior. Our application sends
"Origin-Agent-Cluster: ?0" in response headers to opt-out of Origin Agent clusters since we rely on document.domain. Is this header needed only on document requests or even for script, image, css requests? For some customer, their pages get inside origin-keyed cluster even though the responses contain the header
"Origin-Agent-Cluster: ?0". Is there a bug in the chrome behavior that puts pages in specific cluster? How do we debug what caused the pages to get inside origin-keyed cluster?
W. James MacLean
Sep 7, 2023, 12:30:32 PM9/7/23
to Madanagopal Damodharan, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
If the application is getting loaded inside a tab that has previously loaded other pages from the same origin (i.e. pages not part of the app) that do not have the header, then for consistency the new loads will get OAC isolation even if the header is present. Essentially, the first time the tab loads anything from a particular origin, that determines how it will treat the origin for the remainder of the tab's lifetime. This consistency will also extend to other tabs opened by the tab (as they live in the same "BrowsingInstance").
Also, there may be issues where pages can be loaded from cache without the ?0 version of the header, so two useful steps would be
1) Clear the cache, and
2) open the app directly in a newly opened tab.
I don't think the header needs to be sent on script/css/image requests, as they're used within the context of the .html resource that should have the header.
⭘ W. James MacLean ⭘ Software Engineer ⭘ Google Waterloo, Canada |
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0aa8ac1f-6b52-425f-8e25-f09f55c9e0fdn%40chromium.org.
Madanagopal Damodharan
Sep 10, 2023, 10:23:42 AM9/10/23
to blink-dev, W. James MacLean, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas, Madanagopal Damodharan
Thanks for response. In my case, I am getting the error when a new tab is opened from an existing tab. My existing tab did not throw this error whereas the new tab shows the error on the first request itself. So based on what you mentioned, my parent tab should have been part of Origin-Keyed cluster, right? I am seeing console warning as follows on my new tab that was opened from an existing tab:
"The page did not request an Origin-Keyed agent cluster but was put in one anyway because the origin had previously been placed in an origin-keyed agent cluster. Update your headers to uniformly request origin-keying for all pages on the origin"
"The page did not request an Origin-Keyed agent cluster but was put in one anyway because the origin had previously been placed in an origin-keyed agent cluster. Update your headers to uniformly request origin-keying for all pages on the origin"
I am currently trying to figure out which server response did not have the header ""Origin-Agent-Cluster: ?0" that led my pages to get in origin-keyed cluster. Is there a way (debug tool etc) I can check which response decided Origin-Keying? I think this will be crucial for applications to debug the issues.
One other question: My parent tab has a wss (web socket) request that does not have its response with this OAC header. Do we need the header in wss response as well?
Madanagopal Damodharan
Sep 13, 2023, 11:44:09 AM9/13/23
to blink-dev, Madanagopal Damodharan, W. James MacLean, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
An update on the issue I am facing: We have a static html in web server called signon.html. Users access this static html page first which has a refresh directive with content=1. As soon as the user invokes this html page first time from the origin, this redirects to a login form page. This response contains the header too. But still chrome console says the origin was in origin-keyed cluster. If I change the refresh directive content=5, it takes 5 sec to redirect from signon.html to login form, this time I don't get the console warning. Now I can login and dont see any errors. I am not sure why the refresh directive 5 works but not 1. Is it because Chrome could not capture request and place the origin in appropriate cluster within its 1 second?
Modified the CONTENT=5 from CONTENT=1 in the below line to get it working -
<meta HTTP-EQUIV='Refresh' CONTENT='5; URL=../psp/ps/?cmd=login'>
Any thoughts?
W. James MacLean
Sep 13, 2023, 12:19:00 PM9/13/23
to Madanagopal Damodharan, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
Perhaps try this:
1) open a new tab page (or about:blank if you prefer)
2) right-click and select "Inspect" at the bottom of the popup menu
3) in the DevTools menu at the top, click "Network"
4) then check the "Preserve Logs" checkbox in the row under that menu
5) finally, manually type the url for your app/site in the url bar
As your content loads, the DevTools window will populate with an (in order) list of all the network transactions. You can click on each element in the list and see the response headers for each request. This should help you determine which request is missing the Origin-Agent-Cluster:?0 header and causing the origin keying to be applied for the tab.
Let me know if that helps.
Madanagopal Damodharan
Sep 19, 2023, 10:41:00 PM9/19/23
to blink-dev, W. James MacLean, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas, Madanagopal Damodharan
This helped us identify the response that did not have the header. We noticed that we have a static html called signon.html as our first entry into the application. Since this is a static html, our servlet changes to add response header does not hit when users invoke this signon.html. I think Chrome puts this origin into Origin-keyed cluster at this point and hence when users login and encounter document.domain, they get the error blocked frame error.
meta tags with http-equiv does not recognize this custom response header Origin-Agent-Cluster. Is there a way to add response headers in a static html page response?
W. James MacLean
Sep 25, 2023, 9:53:51 AM9/25/23
to Madanagopal Damodharan, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
No, I think you need to get the server to send the header. Once you get as far as the meta tags, the origin's isolation state has already been decided. I'm not an expert on servers, but my experience in specifying headers to be sent with static pages is to edit the .htaccess file in the directory with the content, and include
HEADER add Origin-Agent-Cluster: ?0
HEADER add Origin-Agent-Cluster: ?0
But the exact details will depend on your setup.
⭘ W. James MacLean ⭘ Software Engineer ⭘ Google Waterloo, Canada |
Madanagopal Damodharan
Oct 6, 2023, 12:41:56 AM10/6/23
to blink-dev, W. James MacLean, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas, Madanagopal Damodharan
Thanks James. We are able to add the header from our server's servlet filter code. It now appends the header for each response including static html files. It seems to be working fine so far. There are instances where it still gets blocked when a link is opened on new window. I believe we need to make sure the new window response contains the header as well, right? Also, if the header gets duplicated i.e. if the response contains the same header twice, it does not work. It looks as if the header is not sent at all. Is this how it is supposed to behave?
W. James MacLean
Oct 12, 2023, 11:30:22 AM10/12/23
to Madanagopal Damodharan, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
While it would obviously be better for the header to only be sent once (less bytes transmitted), I don't think sending it twice should cause a problem so long as both headers are the same, e.g. they both specify "?0". If you're seeing the problem with two headers but not with one, then that's a bug. In that case filing a bug report at crbug.com, including as much information as possible, would be appreciated.
I tried this with a simple test case on my own server, and it seems to work fine.
I tried this with a simple test case on my own server, and it seems to work fine.
Charlie Reis
Oct 12, 2023, 11:51:26 AM10/12/23
to W. James MacLean, Madanagopal Damodharan, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
Actually, I think that's not quite true-- there was a recent report about duplicate headers in https://crbug.com/1478065, and it turns out to be required by spec to not allow duplicates. (See comment 13 on that bug.) I think it will be necessary to only return one copy of the header, and there's a bug filed to have DevTools display a warning in that case.
Charlie
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvoc24scGp3XHZrC%3Dpg7zaUU5OeRLaM9NbS-hbvLRJ06XHQ%40mail.gmail.com.
W. James MacLean
Oct 12, 2023, 12:09:25 PM10/12/23
to Charlie Reis, Madanagopal Damodharan, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
Thanks creis@ ... I learned something new today!
Madanagopal Damodharan
Oct 29, 2023, 11:39:37 AM10/29/23
to W. James MacLean, Charlie Reis, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
Thanks all.
https://crbug.com/1478065 is exactly the issue some of our customers encountered. But unfortunately it didn't give any clue to debug why chrome did not obey the header even if its indeed present though more than once. Hence, it will be helpful to add some warnings or something to indicate on DevTools console why chrome could not interpret the header properly.
D.Madanagopal
David Benjamin
Oct 29, 2023, 11:51:16 AM10/29/23
to Madanagopal Damodharan, W. James MacLean, Charlie Reis, blink-dev, Eiji Kitamura, Daniel Vogelheim, Brandon Heenan, Mike Taylor, Chris Harrelson, Yoav Weiss, Marijke Hoste, Rick Byers, Maud Nalpas
To clarify, rejecting the header is interpreting it properly. It's not that duplicates aren't allowed, it's that there is no such thing as a duplicate header in HTTP. Specifying two headers with the same name is not a no-op. Rather, sending two headers with the same name is simply another syntax for sending one header with the contents concatenated by comma. (With the exception of the Set-Cookie header, which is processed a bit strangely.) This is a holdover from the days when people cared about text protocols being typable via netcat.
So, by sending:
Origin-Agent-Cluster: ?0
Origin-Agent-Cluster: ?0
Origin-Agent-Cluster: ?0
You are really sending:
Origin-Agent-Cluster: ?0, ?0
"?0, ?0" is not a valid Origin-Agent-Cluster, thus it is rejected. A DevTools warning for headers we could not parse would indeed be good, but rejecting it is correct.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHxeoW%2BtSDHv9vNkAWa5Sfd-QAabvJJzDg%2BFtmK2z%2BfdE7XvAQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages