[Webkit-unassigned] [Bug 181587] Fetch API keepAlive is not fully implemented

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 2 01:14:57 PDT 2024


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

Gernot Raudner <gernot.raudner at dynatrace.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gernot.raudner at dynatrace.co
                   |                            |m

--- Comment #7 from Gernot Raudner <gernot.raudner at dynatrace.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240902/342baf54/attachment.htm>


More information about the webkit-unassigned mailing list