Supporting keepalive in Fetch API

385 views
Skip to first unread message

Yutaka Hirano

unread,
Apr 5, 2017, 8:18:14 AM4/5/17
to blink-ne...@chromium.org, Chromium Loading Performance, Takeshi Yoshino, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken
Hi,

We are planning to implement the keepalive option in Fetch API, which is expected to replace current SendBeacon API.

When the option is specified, the fetch operation will continue working after frame destruction. The following design document lists some ideas how to solve the problem.


Some loading-dev folks are interested in moving CORS handling to the browser process, and it is one of possible solutions. So I'm sending this mail to loading-dev@ as well as blink-network-dev@. cc-ing network-servicification people for the topic, too.

Any comments will be appreciated.

Thanks,

Takeshi Yoshino

unread,
Apr 5, 2017, 8:23:10 AM4/5/17
to Yutaka Hirano, Kenji Baheux, igri...@chromium.org, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken
+kenjibaheux, igrigorik

Takeshi

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABihn6HPGCzGXYAv4u6kHure8e8xx-LAgLdVtGqDxkQ4QkBbAA%40mail.gmail.com.

PhistucK

unread,
Apr 5, 2017, 12:19:19 PM4/5/17
to Yutaka Hirano, blink-ne...@chromium.org, Chromium Loading Performance, Takeshi Yoshino, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken
Wait, what - is the send beacon API going away? Or is the underlying implementation just changing?
It is supported by three browsers already (Chrome, Firefox and Edge).


☆PhistucK

--

Kenji Baheux

unread,
Apr 5, 2017, 7:00:24 PM4/5/17
to PhistucK, Yutaka Hirano, blink-ne...@chromium.org, Chromium Loading Performance, Takeshi Yoshino, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken

The doc indicates that deprecating sendbeacon is a long term desire. Apologies for the confusion.


On Thu, Apr 6, 2017, 1:19 AM PhistucK <phis...@gmail.com> wrote:
Wait, what - is the send beacon API going away? Or is the underlying implementation just changing?
It is supported by three browsers already (Chrome, Firefox and Edge).


☆PhistucK
On Wed, Apr 5, 2017 at 3:18 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi,

We are planning to implement the keepalive option in Fetch API, which is expected to replace current SendBeacon API.

When the option is specified, the fetch operation will continue working after frame destruction. The following design document lists some ideas how to solve the problem.


Some loading-dev folks are interested in moving CORS handling to the browser process, and it is one of possible solutions. So I'm sending this mail to loading-dev@ as well as blink-network-dev@. cc-ing network-servicification people for the topic, too.

Any comments will be appreciated.

Thanks,

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABc02_LZkHei-zXxhF99acD_v%3DqLdFY5bXLzONUb%2ByDKFZmSrQ%40mail.gmail.com.

Takeshi Yoshino

unread,
Apr 5, 2017, 8:05:47 PM4/5/17
to Kenji Baheux, PhistucK, Yutaka Hirano, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken
Right. It's only in the distant future. sendBeacon() is widely used. It's not the main intention of the doc.

But it's correct that the proposed long-term direction is that sendBeacon will enter feature freeze state and instead we evolve the Fetch API for further beaconing demands. 

On Thu, Apr 6, 2017 at 8:00 AM, 'Kenji Baheux' via blink-network-dev <blink-ne...@chromium.org> wrote:

The doc indicates that deprecating sendbeacon is a long term desire. Apologies for the confusion.


On Thu, Apr 6, 2017, 1:19 AM PhistucK <phis...@gmail.com> wrote:
Wait, what - is the send beacon API going away? Or is the underlying implementation just changing?
It is supported by three browsers already (Chrome, Firefox and Edge).


☆PhistucK
On Wed, Apr 5, 2017 at 3:18 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi,

We are planning to implement the keepalive option in Fetch API, which is expected to replace current SendBeacon API.

When the option is specified, the fetch operation will continue working after frame destruction. The following design document lists some ideas how to solve the problem.


Some loading-dev folks are interested in moving CORS handling to the browser process, and it is one of possible solutions. So I'm sending this mail to loading-dev@ as well as blink-network-dev@. cc-ing network-servicification people for the topic, too.

Any comments will be appreciated.

Thanks,

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-dev+unsubscribe@chromium.org.
To post to this group, send email to blink-ne...@chromium.org.
 To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/CADWWn7V3Tqen8RCa34tgR4Fws46j_5zSDypw9Dz5brQHTrDCKQ%40mail.gmail.com.

Ilya Grigorik

unread,
Apr 6, 2017, 1:12:13 PM4/6/17
to Takeshi Yoshino, Kenji Baheux, PhistucK, Yutaka Hirano, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken
Design & implement a new mechanism to support the keepalive option in Fetch API.
Reimplement SendBeacon using the mechanism.

^ woohoo! This is great and will hopefully help resolve a few of the long-outstanding interop+security limitations in current sendBeacon implementation.

On Wed, Apr 5, 2017 at 5:05 PM, Takeshi Yoshino <tyos...@chromium.org> wrote:
Right. It's only in the distant future. sendBeacon() is widely used. It's not the main intention of the doc.

But it's correct that the proposed long-term direction is that sendBeacon will enter feature freeze state and instead we evolve the Fetch API for further beaconing demands. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAH9hSJbi__t4_M24JJev3xpV%3DQ7-jQr6O1huH%3DH5zaL1BpHADg%40mail.gmail.com.

Chris Bentzel

unread,
Apr 7, 2017, 5:17:49 PM4/7/17
to Ilya Grigorik, Takeshi Yoshino, Kenji Baheux, PhistucK, Yutaka Hirano, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken
On Thu, Apr 6, 2017 at 1:12 PM 'Ilya Grigorik' via Chromium Loading Performance <loadi...@chromium.org> wrote:
Design & implement a new mechanism to support the keepalive option in Fetch API.
Reimplement SendBeacon using the mechanism.

^ woohoo! This is great and will hopefully help resolve a few of the long-outstanding interop+security limitations in current sendBeacon implementation.

+1 I'm very excited about this. 

On Wed, Apr 5, 2017 at 5:05 PM, Takeshi Yoshino <tyos...@chromium.org> wrote:
Right. It's only in the distant future. sendBeacon() is widely used. It's not the main intention of the doc.

But it's correct that the proposed long-term direction is that sendBeacon will enter feature freeze state and instead we evolve the Fetch API for further beaconing demands. 

On Thu, Apr 6, 2017 at 8:00 AM, 'Kenji Baheux' via blink-network-dev <blink-ne...@chromium.org> wrote:

The doc indicates that deprecating sendbeacon is a long term desire. Apologies for the confusion.


On Thu, Apr 6, 2017, 1:19 AM PhistucK <phis...@gmail.com> wrote:
Wait, what - is the send beacon API going away? Or is the underlying implementation just changing?
It is supported by three browsers already (Chrome, Firefox and Edge).


☆PhistucK
On Wed, Apr 5, 2017 at 3:18 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi,

We are planning to implement the keepalive option in Fetch API, which is expected to replace current SendBeacon API.

When the option is specified, the fetch operation will continue working after frame destruction. The following design document lists some ideas how to solve the problem.


Some loading-dev folks are interested in moving CORS handling to the browser process, and it is one of possible solutions. So I'm sending this mail to loading-dev@ as well as blink-network-dev@. cc-ing network-servicification people for the topic, too.

Any comments will be appreciated.

Thanks,

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.

To post to this group, send email to blink-ne...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Yutaka Hirano

unread,
Oct 2, 2017, 11:37:00 PM10/2/17
to Chris Bentzel, Ilya Grigorik, Takeshi Yoshino, Kenji Baheux, PhistucK, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, haraken, erik...@chromium.org
Hi,

We decided to explore the "Keep renderer alive for a while" direction and I've run a finch experiment on Canary & Dev. I see no significant memory regression. Given the expected security / capability benefits, I would like to enable it and implement the keepalive option on top of the infrastructure.

Thanks,


On Sat, Apr 8, 2017 at 6:17 AM, Chris Bentzel <cben...@chromium.org> wrote:
On Thu, Apr 6, 2017 at 1:12 PM 'Ilya Grigorik' via Chromium Loading Performance <loadi...@chromium.org> wrote:
Design & implement a new mechanism to support the keepalive option in Fetch API.
Reimplement SendBeacon using the mechanism.

^ woohoo! This is great and will hopefully help resolve a few of the long-outstanding interop+security limitations in current sendBeacon implementation.

+1 I'm very excited about this. 
On Wed, Apr 5, 2017 at 5:05 PM, Takeshi Yoshino <tyos...@chromium.org> wrote:
Right. It's only in the distant future. sendBeacon() is widely used. It's not the main intention of the doc.

But it's correct that the proposed long-term direction is that sendBeacon will enter feature freeze state and instead we evolve the Fetch API for further beaconing demands. 

On Thu, Apr 6, 2017 at 8:00 AM, 'Kenji Baheux' via blink-network-dev <blink-network-dev@chromium.org> wrote:

The doc indicates that deprecating sendbeacon is a long term desire. Apologies for the confusion.


On Thu, Apr 6, 2017, 1:19 AM PhistucK <phis...@gmail.com> wrote:
Wait, what - is the send beacon API going away? Or is the underlying implementation just changing?
It is supported by three browsers already (Chrome, Firefox and Edge).


☆PhistucK
On Wed, Apr 5, 2017 at 3:18 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi,

We are planning to implement the keepalive option in Fetch API, which is expected to replace current SendBeacon API.

When the option is specified, the fetch operation will continue working after frame destruction. The following design document lists some ideas how to solve the problem.


Some loading-dev folks are interested in moving CORS handling to the browser process, and it is one of possible solutions. So I'm sending this mail to loading-dev@ as well as blink-network-dev@. cc-ing network-servicification people for the topic, too.

Any comments will be appreciated.

Thanks,

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-dev+unsubscribe@chromium.org.

To post to this group, send email to blink-ne...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Kentaro Hara

unread,
Oct 2, 2017, 11:55:28 PM10/2/17
to Yutaka Hirano, Chris Bentzel, Ilya Grigorik, Takeshi Yoshino, Kenji Baheux, PhistucK, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, Erik Chen
Do you know what percentage of the renderers are kept alive longer in the finch experiment?



On Tue, Oct 3, 2017 at 12:36 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi,




--
Kentaro Hara, Tokyo, Japan

Yutaka Hirano

unread,
Oct 3, 2017, 12:12:18 AM10/3/17
to Kentaro Hara, Chris Bentzel, Ilya Grigorik, Takeshi Yoshino, Kenji Baheux, PhistucK, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, Erik Chen
No. Does that matter?

Please note that renderers are kept alive also for service workers and shared workers. Currently we don't distinguish them.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/CABg10jx8u0YZrQtAS_jJ9_PkRj5UWXLsOFn1iVTYQkH7ECqHxg%40mail.gmail.com.

Kentaro Hara

unread,
Oct 3, 2017, 12:35:11 AM10/3/17
to Yutaka Hirano, Chris Bentzel, Ilya Grigorik, Takeshi Yoshino, Kenji Baheux, PhistucK, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, Erik Chen
No. Does that matter?

I'm wondering how much the keepalive option is used in the finch experiment. If the usage is almost 0, the memory increase should be 0, right?

In other words, have you confirmed the fact that the memory increase is almost 0 while the keepalive option is used to some extent?

Yutaka Hirano

unread,
Oct 3, 2017, 12:49:23 AM10/3/17
to Kentaro Hara, Chris Bentzel, Ilya Grigorik, Takeshi Yoshino, Kenji Baheux, PhistucK, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, Erik Chen
We haven't implemented keepalive option. Instead, already shipped SendBeacon uses the infrastructure. SendBeacon is popular.

Kentaro Hara

unread,
Oct 3, 2017, 12:51:33 AM10/3/17
to Yutaka Hirano, Chris Bentzel, Ilya Grigorik, Takeshi Yoshino, Kenji Baheux, PhistucK, blink-ne...@chromium.org, Chromium Loading Performance, Randy Smith, Matt Menke, John Abd-El-Malek, Mike West, Hiroshige Hayashizaki, ho...@chromium.org, Erik Chen
Thanks, makes sense!

Reply all
Reply to author
Forward
0 new messages