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, On Fri, Sep 1, 2023 at 1:39 AM Ioan-Cristian Linte < linte.ioan.crist...@gmail.com> 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 <ba...@chromium.org> >>> 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 <yoav...@chromium.org> wrote: >>>> >>>>> Friendly ping on the above :) Does (1) sound reasonable from your >>>>> perspective? >>>>> >>>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss <yoav...@chromium.org> >>>>> 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 <pme...@chromium.org> >>>>>> 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 <pme...@chromium.org> >>>>>>> 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 <rvis...@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 to keep me honest >>>>>>>>> >>>>>>>>> On Mon, Mar 13, 2023 at 12:19 AM Yoav Weiss <yoav...@chromium.org> >>>>>>>>> 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 < >>>>>>>>>> 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 <yoav...@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 < >>>>>>>>>>>>>> yoav...@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 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX--xUSXtRBd3YFcvPj9oY6UM5U8ta1qa%3D0_hmg%2BAvL87pA%40mail.gmail.com.
