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/0e5238f8-be2a-4058-92bb-5380d789d250n%40chromium.org.
