[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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 
>>> 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  wrote:
>>>>
>>>>> Friendly ping on the above :) Does (1) sound reasonable from your
>>>>> perspective?
>>>>>
>>>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss 
>>>>> 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=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 
>>>>>> 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 
>>>>>>> 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.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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  wrote:

> Friendly ping on the above :) Does (1) sound reasonable from your
> perspective?
>
> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss  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=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 
>> 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 
>>> 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 
>>>> 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 
>>>>> 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 
>>>>>>> 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.
>>>>>>>>
&

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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  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 
> 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 
>> 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 
>>> 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=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/CAPLXX--BS0Xx1aipT2Nt0hGfkDbgL1qFk-mFQ65%3Dfqj38zoEjg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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 
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  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=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/CAPLXX-9gLUwMLgSzOxMjh9uKqikw2UWsdm9SxG0-maJ7bXp4mA%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship: URLSearchParams.size

[Kenichi Ishibashi]

Contact emailsba...@chromium.org

ExplainerThis is a small extension to URLSearchParams. Web developers can
use the `size` attribute to check whether there are any query parameters in
a URLSearchParams object.

Specificationhttps://url.spec.whatwg.org/#dom-urlsearchparams-size

Summary

Add a size getter to URLSearchParams. It's useful to check whether there
are any query parameters in a URLSearchParams object.


Blink componentBlink


TAG reviewNot applicable. The URL Standard is already updated.

TAG review statusNot applicable

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: Positive (https://github.com/whatwg/url/pull/734)

*Web developers*: Positive (https://github.com/whatwg/url/issues/163)

*Other signals*:

WebView application risks

Debuggability

An attribute can be suspected by DevTools and other tools.

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

?Yes
https://wpt.fyi/results/url/urlsearchparams-size.any.html?label=experimental
(to appear)

Flag nameN/A

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1418374

Estimated milestones

M113


Anticipated spec changes
No.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5197222754385920

This intent message was generated by Chrome Platform Status
.

-- 
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-_OFPuEo8etovj4_HdWgtwvy3QOxOm6XS1e75EVueVgEQ%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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  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=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/CAPLXX-8oNUot5h2cd_XbBQ9ayeYDFJDOfcEVLmNQ%3D15zFXnbtg%40mail.gmail.com.

[blink-dev] Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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


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)

*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.

*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

?Yes
https://wpt.fyi/results/xhr/xhr-authorization-redirect.any.html?label=master=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
.

-- 
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-9yWDEnqEdTcL3f8scEEHVTdmqFFe_tgGTVoOM6%2BaEkQQ%40mail.gmail.com.

Re: [blink-dev] Intent to implement and ship: Allow as=fetch in navigation early hints preload

[Kenichi Ishibashi]

Thank you Yoav for the suggestions! I'll add more words and context next
time.

On Mon, Jan 23, 2023 at 2:18 PM Yoav Weiss  wrote:

> LGTM1
>
> On Mon, Jan 23, 2023 at 2:57 AM Kenichi Ishibashi 
> wrote:
>
>> Contact emailsba...@chromium.org
>>
>> ExplainerNone. This feature is standardized.
>>
>
> It's typically helpful to write a few words that explain the feature and
> the addition to it, even if there's no need for a full fledged explainer
> document for this specific addition.
> For example, you could have linked to the feature's broader explainer
> <https://github.com/bashi/early-hints-explainer/blob/main/explainer.md>,
> and then explain that this adds a new `as` value of "fetch" that would
> enable developers to use Early Hints for resources with that potential
> destination (e.g. `fetch()`ed resources).
>
>
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/semantics.html#attr-link-as
>> https://html.spec.whatwg.org/#early-hints
>>
>> Summary
>>
>> Support  in navigation early hints. This
>> allows web developers to preload resources that are fetched by the fetch()
>> API.
>>
>>
>> Blink componentBlink>Loader>Preload
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader%3EPreload>
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>
> I agree that a TAG review is not needed here, but it's typically better to
> outline the reason.
> In this case, we're adding support for an extra type of resource without
> changing the API's shape or its integration with the rest of the platform.
>
>
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low. The feature is already specified in the HTML and the Fetch standard.
>>
>>
>> *Gecko*: In development (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1407355)
>>
>> *WebKit*: No signal Previously asked in
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html
>>
>> *Web developers*: No signals. We got this feature request from one of
>> our partners.
>>
>
> I would count a feature request as a slightly positive signal.
>
>
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> N/A
>>
>>
>>
>> Debuggability
>>
>> We have a tracking bug
>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1317936> to
>> improve debuggability.
>>
>> 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>
>> ?We will submit a Web Platform Test along with the implementation (Ongoing
>> CL <https://chromium-review.googlesource.com/c/chromium/src/+/4177723>).
>>
>> Flag nameN/A
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1408649
>>
>> Estimated milestones
>>
>> M112
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6195487999262720
>>
>> 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--M%3DZkTz-ZicOW61C9tUJjKvz4cQU49EsnDK7PUG5puGg%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX--M%3DZkTz-ZicOW61C9tUJjKvz4cQU49EsnDK7PUG5puGg%40mail.gmail.com?utm_medium=email_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 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-_O7%2Buvu8VbMox69M7f0E7BeEeZ1BC4frEkoXbytaLbdQ%40mail.gmail.com.

[blink-dev] Intent to implement and ship: Allow as=fetch in navigation early hints preload

[Kenichi Ishibashi]

Contact emailsba...@chromium.org

ExplainerNone. This feature is standardized.

Specification
https://html.spec.whatwg.org/multipage/semantics.html#attr-link-as
https://html.spec.whatwg.org/#early-hints

Summary

Support  in navigation early hints. This allows
web developers to preload resources that are fetched by the fetch() API.


Blink componentBlink>Loader>Preload


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Low. The feature is already specified in the HTML and the Fetch standard.


*Gecko*: In development (
https://bugzilla.mozilla.org/show_bug.cgi?id=1407355)

*WebKit*: No signal Previously asked in
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html

*Web developers*: No signals. We got this feature request from one of our
partners.

*Other signals*:

WebView application risks

N/A



Debuggability

We have a tracking bug
 to improve
debuggability.

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

?We will submit a Web Platform Test along with the implementation (Ongoing
CL ).

Flag nameN/A

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1408649

Estimated milestones

M112


Anticipated spec changes

None


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6195487999262720

This intent message was generated by Chrome Platform Status
.

-- 
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--M%3DZkTz-ZicOW61C9tUJjKvz4cQU49EsnDK7PUG5puGg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: 103 Early Hints for Navigation

[Kenichi Ishibashi]

Yes we would like to ship in 103. Updated the status entry.

On Thu, Apr 28, 2022 at 3:14 AM jmedley via Chromestatus <
admin+jmed...@cr-status.appspotmail.com> wrote:

> Last I heard, you all wanted to ship in 103. Can you please put the
> correct number in the status entry?
>
> --
> 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/8f7e8905dda6c856%40google.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-8vE9yFAu9VeLktuKgbojbYNHCXuEXu-UbYC9ozWjyrqw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Early Hints preload/preconnect during Navigation

[Kenichi Ishibashi]

Hi Yoav,

On Thu, Apr 21, 2022 at 3:26 PM Yoav Weiss  wrote:

>
>
> On Thu, Apr 21, 2022 at 4:13 AM Kenichi Ishibashi 
> wrote:
>
>> Contact emails
>>
>> ba...@chromium.org, denom...@chromium.org
>>
>> Explainer
>>
>> https://github.com/bashi/early-hints-explainer/blob/main/explainer.md
>>
>> Specification
>>
>> https://tools.ietf.org/html/rfc8297
>>
>> https://html.spec.whatwg.org/#early-hints
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit?usp=sharing
>>
>> Summary
>>
>> Support 103 Early Hints informational responses during top-level frame
>> navigation. When a 103 response includes link headers Chromium tries to
>> preload specified resources (including modulepreload) or preconnect to
>> specified origins before the final response is received. This gives Web
>> developers a way to optimize Core Web Vitals such as Largest Contentful
>> Paint (LCP).
>>
>>
>> Blink component
>>
>> Internals>Preload
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload>
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/638
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Browsers may not understand a 103 response but they are expected
>> <https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html#name-informational-1xx>
>> to ignore 1xx responses if they don’t understand 1xx responses. Firefox is
>> implementing 103 support.
>>
>> Proxies may not understand a 103 response. They may treat the 103
>> response as a part of the final response when the response is sent over
>> HTTP/1.1. The problem is less likely to happen over HTTP/2 and HTTP/3
>> thanks to their frame format. Chromium only handles 103 responses over
>> HTTP/2 and HTTP/3.
>>
>> The HTML and Fetch standards have been updated to handle preload link
>> headers in 103 responses for navigations (whatwg/html#7675
>> <https://github.com/whatwg/html/pull/7675>, whatwg/fetch#1404
>> <https://github.com/whatwg/fetch/pull/1404>). For preconnect there are
>> ongoing efforts to specify the behavior. See “Anticipated spec changes”
>> section below for more information.
>>
>> Gecko: In development
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1407355>.
>>
>
> Can you ask for an official position? https://bit.ly/blink-signals
>
I should have put the link to the official position. They said it's worth
prototyping <https://github.com/mozilla/standards-positions/issues/134> and
IIUC it's under development.


>
>>
>> WebKit: No signal
>> <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html>.
>>
>> Web developers: Positive. Positive interest and intent of support by
>> popular CDNs (Fastly
>> <https://www.fastly.com/blog/faster-websites-early-priority-hints>,
>> Cloudflare <https://blog.cloudflare.com/early-hints/>). We've been
>> collaborating with partners to evaluate the impact of Early Hints and we
>> observed significant improvements on page loading metrics such as FCP.
>>
>>
>> Ergonomics
>>
>> The primary usage of this feature is to send link headers to preload
>> resources or preconnect to servers to improve page load performance. Due to
>> potential security concerns Chromium only handles the first 103 response
>> for the top-frame navigation.
>>
>
> That restriction is specified, right? AFAICT, "process early hints headers
> <https://html.spec.whatwg.org/multipage/semantics.html#process-early-hint-headers>"
> is only called from "process a navigate response
> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents:process-early-hint-headers>
> ".
>
Yes, you're right. Sorry for the confusion. Chromium has these restrictions
to follow the specification.


>
>
>> See this document
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/early-hints.md>
>> for details of restrictions. These restrictions may be relaxed in the
>> future.
>>
>>
>> Activation
>>
>> Popular HTTP servers and CDNs provide configurations or options to send
>> Early Hints responses.
>>
>>
>> Security
>>
>> Request mode <https://fetch.spec.whatwg.org/#concept-request-mode> and 
>> credentials
>> mode <https:

[blink-dev] Intent to Ship: Early Hints preload/preconnect during Navigation

[Kenichi Ishibashi]

Contact emails

ba...@chromium.org, denom...@chromium.org

Explainer

https://github.com/bashi/early-hints-explainer/blob/main/explainer.md

Specification

https://tools.ietf.org/html/rfc8297

https://html.spec.whatwg.org/#early-hints

Design docs

https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit?usp=sharing

Summary

Support 103 Early Hints informational responses during top-level frame
navigation. When a 103 response includes link headers Chromium tries to
preload specified resources (including modulepreload) or preconnect to
specified origins before the final response is received. This gives Web
developers a way to optimize Core Web Vitals such as Largest Contentful
Paint (LCP).


Blink component

Internals>Preload


TAG review

https://github.com/w3ctag/design-reviews/issues/638

TAG review status

Issues addressed

Risks
Interoperability and Compatibility

Browsers may not understand a 103 response but they are expected

to ignore 1xx responses if they don’t understand 1xx responses. Firefox is
implementing 103 support.

Proxies may not understand a 103 response. They may treat the 103 response
as a part of the final response when the response is sent over HTTP/1.1.
The problem is less likely to happen over HTTP/2 and HTTP/3 thanks to their
frame format. Chromium only handles 103 responses over HTTP/2 and HTTP/3.

The HTML and Fetch standards have been updated to handle preload link
headers in 103 responses for navigations (whatwg/html#7675
, whatwg/fetch#1404
). For preconnect there are
ongoing efforts to specify the behavior. See “Anticipated spec changes”
section below for more information.

Gecko: In development 
.

WebKit: No signal
.

Web developers: Positive. Positive interest and intent of support by
popular CDNs (Fastly
,
Cloudflare ). We've been
collaborating with partners to evaluate the impact of Early Hints and we
observed significant improvements on page loading metrics such as FCP.


Ergonomics

The primary usage of this feature is to send link headers to preload
resources or preconnect to servers to improve page load performance. Due to
potential security concerns Chromium only handles the first 103 response
for the top-frame navigation. See this document

for details of restrictions. These restrictions may be relaxed in the
future.


Activation

Popular HTTP servers and CDNs provide configurations or options to send
Early Hints responses.


Security

Request mode  and
credentials
mode  are
calculated the same as normal preload and preconnect. Preloads triggered by
a 103 response follow policies specified in the same 103 response. Chromium
only handles the first 103 response and ignores following 103 responses to
avoid contradiction policies between these responses and the final
response. Chromium doesn’t use preloaded resources triggered by a 103
response when there are conflicting policies between a 103 response and the
final response. See the security considerations section

of the design doc for more information.


WebView application risks

We don’t expect WebView specific problems with this feature.


Debuggability

If a resource is preloaded by Early Hints, the corresponding
PerformanceResourceTiming object reports that its initiatorType is
"early-hints".

When the document doesn’t use resources preloaded by Early Hints within a
few seconds from the window’s load event Chromium will show warning
messages (this is under review now).

DevTools lack Early Hints support and we consider adding Early Hints
support in DevTools in the future. In the meanwhile developers can use
NetLog ,
WebPageTest, or network protocol analyzers such as Wireshark for debugging.

Is this feature fully tested by web-platform-tests

?

Yes


Flag name

EarlyHintsPreloadForNavigation

Requires code in //chrome?

False

Tracking bug

https://crbug.com/671310

Launch bug

https://crbug.com/1197989

Sample links

https://early-hints.fastlylabs.com/

Estimated 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Kenichi Ishibashi]

Clarification: I'm talking about the experiment evaluating the effect of
using Early Hints. We have been collaborating with a CDN and their
customers for the experiment.

On Thu, Dec 9, 2021 at 9:08 AM Kenichi Ishibashi  wrote:

> We have early results that indicate improvements on FCP/LCP. We'd like to
> talk to some experiment participants to confirm these results.
>
> On Thu, Dec 9, 2021 at 3:06 AM yue li  wrote:
>
>> It's 3 weeks now, we're waiting for the update. Anything I missed?
>>
>> 在2021年11月17日星期三 UTC+8 00:08:26 写道：
>>
>>> Hi,
>>>
>>> We are waiting on results from an ongoing experiment to confirm that
>>> Early Hints works and improves performance. There should be an update
>>> in three weeks.
>>>
>>> Bence
>>>
>>> On Thu, Nov 11, 2021 at 7:50 PM Daniel Micay 
>>> wrote:
>>> >
>>> > It's now a year since the removal of HTTP/2 push was announced and
>>> Chromium still has HTTP/2 push. Are you waiting until browsers and servers
>>> implement 103 Early Hints? We use push but we halted optimizing it further
>>> due to the announced removal.
>>>
>> --
>> 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/5bf6cbf0-3b96-4bdd-9a9a-cb1f10b76f1fn%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5bf6cbf0-3b96-4bdd-9a9a-cb1f10b76f1fn%40chromium.org?utm_medium=email_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 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-92vOHGifkccRS9oGh84aMmoBu0OCTX23xacn0PTnJBgg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Kenichi Ishibashi]

We have early results that indicate improvements on FCP/LCP. We'd like to
talk to some experiment participants to confirm these results.

On Thu, Dec 9, 2021 at 3:06 AM yue li  wrote:

> It's 3 weeks now, we're waiting for the update. Anything I missed?
>
> 在2021年11月17日星期三 UTC+8 00:08:26 写道：
>
>> Hi,
>>
>> We are waiting on results from an ongoing experiment to confirm that
>> Early Hints works and improves performance. There should be an update
>> in three weeks.
>>
>> Bence
>>
>> On Thu, Nov 11, 2021 at 7:50 PM Daniel Micay  wrote:
>> >
>> > It's now a year since the removal of HTTP/2 push was announced and
>> Chromium still has HTTP/2 push. Are you waiting until browsers and servers
>> implement 103 Early Hints? We use push but we halted optimizing it further
>> due to the announced removal.
>>
> --
> 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/5bf6cbf0-3b96-4bdd-9a9a-cb1f10b76f1fn%40chromium.org
> 
> .
>

-- 
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-_GqnRzU8Bb9fUwNjc93AtLeD3YoBeR9ztdh4S%3DCfXX4Q%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Origin Trial: Early Hints preload/preconnect during Navigation

[Kenichi Ishibashi]

Hi Anne,

We plan to start working on the spec issue in this quarter.

Thanks,

On Tue, Nov 2, 2021 at 5:47 PM Anne van Kesteren  wrote:

> On Thu, Oct 7, 2021 at 8:39 AM Kenichi Ishibashi 
> wrote:
> > Specification
> >
> > https://tools.ietf.org/html/rfc8297
>
> When do you expect to make progress on
> https://github.com/whatwg/fetch/issues/1225? The RFC doesn't fully
> define this feature.
>

-- 
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-_aKo0yC%3DX5C-81FBQFdJq056mD7dHv8MaDRS7R27OkBA%40mail.gmail.com.

[blink-dev] Intent to Extend Origin Trial: Early Hints preload/preconnect during Navigation

[Kenichi Ishibashi]

We would like to extend Early Hints preload/preconnect Origin Trial to M98
(originally planned to end in M96).

Contact emailsba...@chromium.org, yhir...@chromium.org,
denom...@chromium.org

Explainer
https://github.com/bashi/early-hints-explainer/blob/main/explainer.md

Specificationhttps://tools.ietf.org/html/rfc8297

Design docs
https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit?usp=sharing

Summary

Support 103 Early Hints informational responses for navigation. When a 103
response includes  or other link headers Chromium tries
to preload (and/or preconnect, prefetch) specified resources even before
the final response is received. This gives Web developers a way to optimize
Core Web Vitals such as Largest Contentful Paint (LCP).


Blink componentInternals>Preload


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/638

TAG review statusPending

Risks


Interoperability and Compatibility

Several servers/proxies may not understand a 103 response. They may treat
the 103 response as a part of the final response when the response is sent
over HTTP/1.1. The problem is less likely to happen over HTTP/2 thanks to
their frame format. Chromium only handles 103 responses over HTTP/2 and
HTTP/3.


Gecko: Worth prototyping (
https://github.com/mozilla/standards-positions/issues/134)

WebKit: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html)

Web developers: Positive (
https://www.fastly.com/blog/faster-websites-early-priority-hints) Web
developers: Positive (
https://www.fastly.com/blog/faster-websites-early-priority-hints) Positive
interest and intent of support by popular CDNs. We've been collaborating
with Fastly to do the preliminary measurement.


Goals for experimentation

Allows web developers to opt-in Early Hints preloads. We use custom page
load metrics (FCP, LCP FID) to measure performance impact.


Reason this experiment is being extended

We added preconnect support in M95 based on Web developer's feedback and we
are now evaluating the impact of preload and preconnect. We realized that
we need more time to evaluate the impact of this feature. We have partners
lined up for the feature and we expect to get more data in coming months.

Ongoing technical constraints

None

Debuggability

If a resource is preloaded by Early Hints, the corresponding
PerformanceResourceTiming object reports initiatorType is "early-hints".
For more details, see
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/early-hints.md#checking-early-hints-preload-is-working


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

?No

Flag nameEarlyHintsPreloadForNavigation

Requires code in //chrome?False

Tracking bughttps://crbug.com/671310

Launch bughttps://crbug.com/1197989

Estimated milestones
OriginTrial desktop last 95 → *98*
OriginTrial desktop first 94
OriginTrial android last 95 → *98*
OriginTrial android first 94

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5207422375297024

Links to previous Intent discussionsIntent to Experiment:
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/xb_NHDS3twY


This intent message was generated by Chrome Platform Status
.

-- 
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-8G77uvOt6%3DomTRhQBS%2BcmxB6UaAbeeHiKRRumMPnd8bg%40mail.gmail.com.

[blink-dev] Re: Intent to Experiment: 103 Early Hints preload during Navigation

[Kenichi Ishibashi]

Hi Yoav,

On Fri, Aug 27, 2021 at 5:25 PM Yoav Weiss  wrote:

> I think the addition is reasonable, and it makes perfect sense to add it
> as part of the same Origin Trial.
> Is the addition a result of feedback from OT participants? If so, I think
> it makes sense to add that support without requiring much process.
>
Yes, we got feedback from our partners that preconnect will be beneficial
to them.


>
> On Fri, Aug 27, 2021 at 9:45 AM Kenichi Ishibashi 
> wrote:
>
>> Hi API owners,
>>
>> We would like to add preconnect [1] support in this experiment. The
>> purpose of preconnect is similar to preload but it's more lightweight:
>> preload tries to fetch resources, preconnect just tries to establish
>> connections. If this addition is reasonable, we will update relevant
>> documents and work on relevant spec works.
>>
>
> Updating the documentation seems critical, so thanks for doing that!
>
>
>>
>> [1] https://www.w3.org/TR/resource-hints/#preconnect
>>
>>
>> On Wed, Jul 28, 2021 at 10:29 AM Kenichi Ishibashi 
>> wrote:
>>
>>> Hi blink-dev,
>>>
>>> We now plan to run an origin trial for Early Hints preload. We realized
>>> that running an origin trial is useful for developers to try the feature.
>>> CL for integrating with the origin trial frame is under review. Experiment
>>> timeline unchanged (until M95).
>>>
>>> Thanks,
>>>
>>> On Thu, Jun 17, 2021 at 6:42 PM Yoav Weiss 
>>> wrote:
>>>
>>>> Still LGTM. I agree that being able to monitor support for a
>>>> performance optimization is a crucial part of the experiment.
>>>>
>>>> On Thu, Jun 17, 2021 at 11:01 AM Kenichi Ishibashi 
>>>> wrote:
>>>>
>>>>> Hi API owners,
>>>>>
>>>>> Regarding a PerformanceResourceTiming change for monitoring, we are
>>>>> going to add a new value "early-hints" for `initiatorType` [1].
>>>>>
>>>>> We consider this web-exposing change is a crucial part of this intent
>>>>> to experiment. We would like to make the change as a part of this intent. 
>>>>> I
>>>>> added a section for the change to the design doc [2]. The explainer for 
>>>>> TAG
>>>>> review also mentions the change [3].
>>>>>
>>>>> Please let us know if we need a separate intent for the change.
>>>>>
>>>>> [1] https://github.com/w3c/resource-timing/issues/273
>>>>> [2]
>>>>> https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit#heading=h.vsk6lnrdp6xp
>>>>> [3]
>>>>> https://github.com/bashi/early-hints-explainer/blob/main/explainer.md#extension-to-the-performanceresourcetiming
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Fri, May 21, 2021 at 3:55 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> LGTM to experiment M91-M95
>>>>>>
>>>>>> On Fri, May 21, 2021 at 1:15 AM Kenichi Ishibashi 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Yoav, sorry for the late reply.
>>>>>>>
>>>>>>> On Wed, May 19, 2021 at 6:38 PM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks for experimenting with this!
>>>>>>>>
>>>>>>>> What's the plan in terms of monitoring? I know we discussed offline
>>>>>>>> the possibility of adding an Early Hints indication as part of
>>>>>>>> Resource Timing <https://github.com/w3c/resource-timing/issues/273>
>>>>>>>> .
>>>>>>>> Is that planned to be part of that experiment? Or are you planning
>>>>>>>> to send a separate intent for that?
>>>>>>>>
>>>>>>>
>>>>>>> We likely propose adding a new attribute to
>>>>>>> PerformanceResourceTiming or adding a new value for `initiatorType`. I'm
>>>>>>> planning to send a separate intent as needed.
>>>>>>>
>>>>>>
>>>>>> That sounds great, thanks! :)
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Wed, May 19, 2021 at 3:31 AM Kenichi Ishibashi <
>>>>>>>> ba...@

[blink-dev] Re: Intent to Experiment: 103 Early Hints preload during Navigation

[Kenichi Ishibashi]

Hi API owners,

We would like to add preconnect [1] support in this experiment. The purpose
of preconnect is similar to preload but it's more lightweight: preload
tries to fetch resources, preconnect just tries to establish connections.
If this addition is reasonable, we will update relevant documents and work
on relevant spec works.

[1] https://www.w3.org/TR/resource-hints/#preconnect


On Wed, Jul 28, 2021 at 10:29 AM Kenichi Ishibashi 
wrote:

> Hi blink-dev,
>
> We now plan to run an origin trial for Early Hints preload. We realized
> that running an origin trial is useful for developers to try the feature.
> CL for integrating with the origin trial frame is under review. Experiment
> timeline unchanged (until M95).
>
> Thanks,
>
> On Thu, Jun 17, 2021 at 6:42 PM Yoav Weiss  wrote:
>
>> Still LGTM. I agree that being able to monitor support for a performance
>> optimization is a crucial part of the experiment.
>>
>> On Thu, Jun 17, 2021 at 11:01 AM Kenichi Ishibashi 
>> wrote:
>>
>>> Hi API owners,
>>>
>>> Regarding a PerformanceResourceTiming change for monitoring, we are
>>> going to add a new value "early-hints" for `initiatorType` [1].
>>>
>>> We consider this web-exposing change is a crucial part of this intent to
>>> experiment. We would like to make the change as a part of this intent. I
>>> added a section for the change to the design doc [2]. The explainer for TAG
>>> review also mentions the change [3].
>>>
>>> Please let us know if we need a separate intent for the change.
>>>
>>> [1] https://github.com/w3c/resource-timing/issues/273
>>> [2]
>>> https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit#heading=h.vsk6lnrdp6xp
>>> [3]
>>> https://github.com/bashi/early-hints-explainer/blob/main/explainer.md#extension-to-the-performanceresourcetiming
>>>
>>> Thanks,
>>>
>>> On Fri, May 21, 2021 at 3:55 PM Yoav Weiss 
>>> wrote:
>>>
>>>> LGTM to experiment M91-M95
>>>>
>>>> On Fri, May 21, 2021 at 1:15 AM Kenichi Ishibashi 
>>>> wrote:
>>>>
>>>>> Hi Yoav, sorry for the late reply.
>>>>>
>>>>> On Wed, May 19, 2021 at 6:38 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> Thanks for experimenting with this!
>>>>>>
>>>>>> What's the plan in terms of monitoring? I know we discussed offline
>>>>>> the possibility of adding an Early Hints indication as part of
>>>>>> Resource Timing <https://github.com/w3c/resource-timing/issues/273>.
>>>>>> Is that planned to be part of that experiment? Or are you planning to
>>>>>> send a separate intent for that?
>>>>>>
>>>>>
>>>>> We likely propose adding a new attribute to PerformanceResourceTiming
>>>>> or adding a new value for `initiatorType`. I'm planning to send a separate
>>>>> intent as needed.
>>>>>
>>>>
>>>> That sounds great, thanks! :)
>>>>
>>>>
>>>>>
>>>>>
>>>>>> On Wed, May 19, 2021 at 3:31 AM Kenichi Ishibashi 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Mike, thank you for your questions!
>>>>>>>
>>>>>>> On Tue, May 18, 2021 at 6:31 PM Mike West 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi <
>>>>>>>> ba...@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> Contact emails
>>>>>>>>>
>>>>>>>>> ba...@chromium.org, kin...@chromium.org, yhir...@chromium.org
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>>
>>>>>>>>> https://tools.ietf.org/html/rfc8297
>>>>>>>>>
>>>>>>>>> Link to “Intent to Prototype” blink-dev discussion
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>>
>>>>>>>>> When a 103 Early Hints response is received during navigation and
>>>&