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.

Reply via email to