Hey, Sorry for necro'ing this thread, I'm aware that this has been on the "done" pile for a while - and maybe it should've been brought up earlier, but how do you "disable" this feature ? It's making the BE dev exhaustingly painful, not being able to intercept requests and re-forward them to the local BE. Is there a flag, or whatnot, to re-enable the old flow ? Thanks
On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote: > LGTM3 > > On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor <[email protected]> wrote: > >> LGTM2 >> On 9/3/23 8:12 PM, Yoav Weiss wrote: >> >> LGTM1 >> >> >> >> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi <[email protected]> >> wrote: >> >>> Hi, sorry for the long delay. >>> >>> The feature page >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4470> now >>> shows sites that use Authorization header for cross-origin redirects. I >>> randomly picked some of them and examined to see if they could work when >>> Chrome removes Authorization header up on cross-origin redirects. As far as >>> I can tell, none of them are broken. We would like to ship this behind a >>> feature flag. >>> >> >> Thanks for the analysis! >> As you pointed out elsewhere, since our previous discussions on this >> thread, this was shipped >> <https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=stable&label=master&aligned> >> >> by Firefox and Safari. >> I think that changes the risk calculus (from compat to interop) and makes >> shipping this (with a base feature just in case) the right choice. >> >> >>> Thanks, >>> >>> On Fri, Sep 1, 2023 at 1:39 AM Ioan-Cristian Linte < >>> [email protected]> wrote: >>> >>>> Any updates on this? >>>> Other browser have already made the change for some time so it's >>>> surprising that Chrome is so worried about breaking change. >>>> >>>> The Authorization propagating in cross origin redirects is causing a >>>> performance issue for us. Our server redirects to AWS S3 with pre-signed >>>> url and this will return 400 error as AWS S3 disallows specifying multiple >>>> authorizations (e.g. signature in url and Authorization header) in a >>>> request. Also the 400 error response includes a close connection header. >>>> To >>>> make this work, the web client checks for the 400 error and uses the >>>> response.url to make a new fetch request without the Authorization header. >>>> Because the previous connection was closed this incurs the cost of >>>> initiating a new connection. >>>> >>>> On Wednesday, June 28, 2023 at 6:34:42 PM UTC+3 Yoav Weiss wrote: >>>> >>>>> Friendly ping! :) Any news on UKM data here? >>>>> >>>>> On Wednesday, April 5, 2023 at 10:53:41 AM UTC+2 Yoav Weiss wrote: >>>>> >>>>>> Sounds great, thanks!! :) >>>>>> >>>>>> On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Yoav, >>>>>>> >>>>>>> Sorry I haven't sent an update in this thread. (1) sounds >>>>>>> reasonable. I added the usercounters to UKM a few weeks ago and I'm >>>>>>> waiting >>>>>>> for data. I will report back after manual inspections are done. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 5, 2023 at 5:14 PM Yoav Weiss <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Friendly ping on the above :) Does (1) sound reasonable from your >>>>>>>> perspective? >>>>>>>> >>>>>>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The way I see this, given that the usecounter is an order of >>>>>>>>> magnitude higher than what we can consider trivial, we have 3 >>>>>>>>> options: >>>>>>>>> 1) Add the usecounters to UKM >>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=32?q=usecounters%20ukm&ss=chromium>, >>>>>>>>> >>>>>>>>> run an analysis on early data to extract URLs that use this, and >>>>>>>>> randomly >>>>>>>>> sample those for manual inspection. >>>>>>>>> 2) Wait for the HTTPArchive crawl to run with this usecounter, >>>>>>>>> assuming that unauthed landing pages will trigger it. >>>>>>>>> 3) Run an HA query that tries to find cross-origin redirects with >>>>>>>>> Auth headers. I'm not sure how easy (or feasible) that would be, but >>>>>>>>> Rick >>>>>>>>> and Pat would know >>>>>>>>> >>>>>>>>> To me, (1) seems to be the easiest, and with the least amount of >>>>>>>>> potential bias (all pages vs. unauthed landing pages). >>>>>>>>> >>>>>>>>> On Tue, Mar 14, 2023 at 9:45 PM Patrick Meenan < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Do we expect the Authorization header to be something that the >>>>>>>>>> HTTP Archive triggers in a way that the feature will trigger? Since >>>>>>>>>> they >>>>>>>>>> are all unauthenticated single page loads, it feels like it's >>>>>>>>>> unlikely to >>>>>>>>>> be something that we hit. >>>>>>>>>> >>>>>>>>>> On Tue, Mar 14, 2023 at 4:37 PM Patrick Meenan < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> 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 <[email protected]> >>>>>>>>>>> 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 to keep me honest >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 13, 2023 at 12:19 AM Yoav Weiss < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> It's possible that we need to wait for the next HA run to get >>>>>>>>>>>>> actual examples. >>>>>>>>>>>>> +Rick Viscomi would know.. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 13, 2023 at 12:28 AM Kenichi Ishibashi < >>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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 [email protected] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 Status >>>>>>>>>>>>>>>>>> https://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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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/01f78357-99e8-4233-8125-1233bd8bc786%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01f78357-99e8-4233-8125-1233bd8bc786%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/d47022cf-5f27-4d9b-97f3-bb9c71d814d8n%40chromium.org.
