Looks like the feature flag was added Feb 16 <https://chromium-review.googlesource.com/c/chromium/src/+/4235597> which looks like it should have made the 112 branch point <https://chromiumdash.appspot.com/schedule>. If we hold the April crawl back a couple of days and start it on the 4th after stable is released then we can pick it up in April, otherwise it would show up mid-crawl.
On Tue, Mar 14, 2023 at 4:24 PM Rick Viscomi <rvisc...@google.com> wrote: > Am I reading the feature page > <https://chromestatus.com/feature/5195900413018112> correctly that it'll > land in stable version 113? If so, HTTP Archive wouldn't pick that up until > the May crawl. > > cc @Patrick Meenan <pmee...@chromium.org> to keep me honest > > On Mon, Mar 13, 2023 at 12:19 AM Yoav Weiss <yoavwe...@chromium.org> > wrote: > >> It's possible that we need to wait for the next HA run to get actual >> examples. >> +Rick Viscomi <rvisc...@google.com> would know.. >> >> On Mon, Mar 13, 2023 at 12:28 AM Kenichi Ishibashi <ba...@chromium.org> >> wrote: >> >>> Thank you Yoav for the suggestion. I couldn't find sample URLs from the >>> HTTPArchive data (feature usage >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4470>). >>> I'll add a feature flag to prepare for reverting this change if breakage is >>> problematic. >>> >>> On Fri, Mar 10, 2023 at 7:06 PM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> One option to tighten the potential for breakage would be to e.g. >>>> sample 10 URLs that are hitting that usecounter (e.g. from the HTTPArchive >>>> data), and test them manually to see how many of them would break once this >>>> change is applied. Based on the number you'd get, we can estimate the >>>> magnitude of breakage we can expect to see in the wild. >>>> Another option would be to roll this out with a base feature flag (that >>>> we'd want anyway) and be ready to revert if breakage is more than we'd >>>> like. >>>> >>>> Combining those two options is probably safest. >>>> >>>> On Fri, Mar 10, 2023 at 8:51 AM Kenichi Ishibashi <ba...@chromium.org> >>>> wrote: >>>> >>>>> Use counter reports 0.022%. My guess is that most usage happens >>>>> accidentally but we are not sure. >>>>> >>>>> API owners, should we do a reverse OT? >>>>> >>>>> On Fri, Feb 17, 2023 at 9:38 AM Kenichi Ishibashi <ba...@chromium.org> >>>>> wrote: >>>>> >>>>>> Quick update, we added a use counter to see how often this >>>>>> could happen. I'll get back once we have data. >>>>>> >>>>>> >>>>>> On Wed, Feb 8, 2023 at 11:51 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Any use counters on how often this happens? >>>>>>> >>>>>>> On Thursday, February 2, 2023 at 8:58:35 AM UTC+1 Kenichi Ishibashi >>>>>>> wrote: >>>>>>> Contact emailsba...@chromium.org >>>>>>> >>>>>>> Specificationhttps://fetch.spec.whatwg.org/#http-redirect-fetch >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> Remove Authorization header on cross origin redirects to scope a >>>>>>> developer-controlled Authorization header to the origin of the initial >>>>>>> request. >>>>>>> >>>>>>> Blink componentBlink>Loader >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> >>>>>>> >>>>>>> TAG review >>>>>>> Not applicable, the spec has been already updated. >>>>>>> https://github.com/whatwg/fetch/pull/1544 >>>>>>> >>>>>>> TAG review statusNot applicable >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> Low. All browser vendors agreed with this change. >>>>>>> >>>>>>> *Gecko*: Shipping (https://bugzilla.mozilla.org/ >>>>>>> show_bug.cgi?id=1802086) >>>>>>> >>>>>>> Do we know if they ran into any compat issues when shipping this? >>>>>>> >>>>>> None I'm aware of. I checked the bug and related issues in GitHub but >>>>>> I didn't find anything. >>>>>> >>>>>> >>>>>>> >>>>>>> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_ >>>>>>> bug.cgi?id=230935) Historically Safari always removed Authorization >>>>>>> headers even for the same origin redirects. Recently the behavior has >>>>>>> changed to preserve them on same origin redirects. >>>>>>> >>>>>>> That's encouraging in terms of lack of potential reliance on these >>>>>>> headers. >>>>>>> >>>>>>> >>>>>>> *Web developers*: No signals >>>>>>> >>>>>>> *Other signals*: >>>>>>> >>>>>>> WebView application risks >>>>>>> >>>>>>> N/A >>>>>>> >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> Web Developers can use DevTools network panel to see the actual >>>>>>> request headers. >>>>>>> >>>>>>> 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 >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ?Yes >>>>>>> https://wpt.fyi/results/xhr/xhr-authorization-redirect. >>>>>>> any.html?label=master&label=experimental >>>>>>> https://wpt.fyi/results/fetch/api/credentials/ >>>>>>> authentication-redirection.any.html?label=experimental >>>>>>> >>>>>>> Flag nameNot applicable >>>>>>> >>>>>>> Requires code in //chrome?False >>>>>>> >>>>>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id= >>>>>>> 1393520 >>>>>>> >>>>>>> Estimated milestones >>>>>>> >>>>>>> M112 >>>>>>> >>>>>>> Anticipated spec changes >>>>>>> >>>>>>> The spec has been already updated. >>>>>>> >>>>>>> https://github.com/whatwg/fetch/issues/944 >>>>>>> >>>>>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/ >>>>>>> feature/5195900413018112 >>>>>>> >>>>>>> This intent message was generated by Chrome Platform Status >>>>>>> <https://chromestatus.com/>. >>>>>>> >>>>>> -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w7L5snOoKRM5zZUEbtpuGqSk1Htt3JW8CaB%2Bfd9k_2w4A%40mail.gmail.com.