Bug 181587 – Fetch API keepAlive is not fully implemented

• Status: NEW
• Component: Service Workers

[youenn fablet]

Fetch API keepAlive is using the regular load backend.
Using the ping load backend would be easy but would cause:
- fetch API keepalive responses would have no body
- fetch API keepalive requests would not be intercepted by service workers

One possibility is to have a runtime flag for keepAlive until our implementation is complete.

[Radar WebKit Bug Importer]

<rdar://problem/36465821>

[Yoav Weiss]

I'm highly in favor of a runtime flag off-by-default, as the current situation where the feature is exposed but incomplete poses a compatibility risk. 

Regarding moving to the ping load backend, I'm not sure:
* No response body - for the main use-case for Fetch keepalive (as a improvement on `sendBeacon()`), that's probably fine, as we don't care about the response at all. I don't know if other use-cases have come up since, which do care about the response.
* No Service Worker interception - That seems like a significant limitation. I can imagine folks who'd want to e.g. convert beacons into background sync when offline, augment their beacon requests with SW data, etc.

[youenn fablet]

> Regarding moving to the ping load backend, I'm not sure:
> * No response body - for the main use-case for Fetch keepalive (as a
> improvement on `sendBeacon()`), that's probably fine, as we don't care about
> the response at all. I don't know if other use-cases have come up since,
> which do care about the response.

Upgrading ping load to send responses seems fine to me.
In the end, ping load could be the base for the regular loading code path.

> * No Service Worker interception - That seems like a significant limitation.
> I can imagine folks who'd want to e.g. convert beacons into background sync
> when offline, augment their beacon requests with SW data, etc.

Supporting that mandates the support of fetch API keepAlive.
Would you be able to file a bug for it? Is there any related WPT test?

[youenn fablet]

> * No Service Worker interception - That seems like a significant limitation.
> I can imagine folks who'd want to e.g. convert beacons into background sync
> when offline, augment their beacon requests with SW data, etc.

To be clear, WebKit does not yet support service worker interception of beacon API requests.

[Yoav Weiss]

(In reply to youenn fablet from comment #4)
> > * No Service Worker interception - That seems like a significant limitation.
> > I can imagine folks who'd want to e.g. convert beacons into background sync
> > when offline, augment their beacon requests with SW data, etc.
> 
> To be clear, WebKit does not yet support service worker interception of
> beacon API requests.

No support yet is probably fine. I was afraid you're saying that going the ping load backend means there won't ever be support for such requests.

I failed to find WPT tests that test for beacon being intercepted :/ I'll file a separate bug for beacon/SW support.

[Yoav Weiss]

Submitted https://bugs.webkit.org/show_bug.cgi?id=181671

[Gernot Raudner]

sorry to bump this old thing, but since mozilla is finally working on fixing their fetch keepalive implementation, i thought it might be a good time to also fix it here.

> * No response body - for the main use-case for Fetch keepalive (as a improvement on `sendBeacon()`), that's probably fine, as we don't care about the response at all. I don't know if other use-cases have come up since, which do care about the response.

i think the main use case is to replace navigator.sendBeacon with fetch keepalive, yes. but dropping the response is somewhat a downgrade. here's an example:

you have a request you want to send in non-regular intervals where you're interested in a response (e.g. social media website that both updates your online status and responds with the online status of your friends). in general, you're interested in the response, but it's not necessary if you leave the page. however, it's important that the request goes through (marking you as offline).

you can't _always_ use sendBeacon for it because you're interested in the response, and you can't _only_ use sendBeacon in pagehide because what if a request was already triggered right before page hide that used regular fetch?

this is exactly the scenario where fetch keepalive really shines: you can rely on the data always being sent, and you can rely on always receiving data if the user doesn't leave the page.