On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki <[email protected]> wrote:
> 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 ? > Can you expand on the issue you're hitting? By "BE" do you mean backend? Or something else? > 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/CAOmohS%2Bdjyw27b-czab4fAKYPSMBh8AfxJJvRu%3DtZc5PgAGTcQ%40mail.gmail.com.
