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.
<rdar://problem/36465821>
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.
> 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?
> * 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.
(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.
Submitted https://bugs.webkit.org/show_bug.cgi?id=181671