WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
181587
Fetch API keepAlive is not fully implemented
https://bugs.webkit.org/show_bug.cgi?id=181587
Summary
Fetch API keepAlive is not fully implemented
youenn fablet
Reported
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2018-01-12 03:21:02 PST
<
rdar://problem/36465821
>
Yoav Weiss
Comment 2
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.
youenn fablet
Comment 3
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?
youenn fablet
Comment 4
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.
Yoav Weiss
Comment 5
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.
Yoav Weiss
Comment 6
2018-01-16 00:09:23 PST
Submitted
https://bugs.webkit.org/show_bug.cgi?id=181671
Gernot Raudner
Comment 7
2024-09-02 01:14:57 PDT
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug