Bug 181587 - Fetch API keepAlive is not fully implemented
Summary: Fetch API keepAlive is not fully implemented
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Service Workers (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-01-12 03:13 PST by youenn fablet
Modified: 2018-01-16 00:09 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2018-01-12 03:13:09 PST
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.
Comment 1 Radar WebKit Bug Importer 2018-01-12 03:21:02 PST
<rdar://problem/36465821>
Comment 2 Yoav Weiss 2018-01-12 04:28:18 PST
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.
Comment 3 youenn fablet 2018-01-12 04:40:00 PST
> 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?
Comment 4 youenn fablet 2018-01-12 07:09:46 PST
> * 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.
Comment 5 Yoav Weiss 2018-01-15 23:46:42 PST
(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.
Comment 6 Yoav Weiss 2018-01-16 00:09:23 PST
Submitted https://bugs.webkit.org/show_bug.cgi?id=181671