Description
Introduction
Back in #1464, it was reported that KeepAlive: true interacts with fetch in a way that limits POST request body sizes.
This behavior is specified in https://fetch.spec.whatwg.org/#http-network-or-cache-fetch
If contentLengthValue is non-null and httpRequest’s keepalive flag is set, then: [...] If the sum of contentLengthValue and inflightKeepaliveBytes is greater than 64 kibibytes, then return a network error.
I found a discussion about KeepAlive in the fetch API in blink-dev Chromium group that gives some insight on the use cases it was meant to support, as well as a design document of keepalive support on Fetch API.
A web developer can use the feature to report events, state updates and analytics with small amount of data even when the page is about to be unloaded. This is useful for analytics and other cases where async delivery of data is required without blocking navigations, and lessens the need for synchronous XHR which is bad for user experience.
This sounds like what Sentry is and does.
The discussion thread also has questioning about the payload size limit, which is a security feature preventing pages from leaking memory arbitrarily.
What Fetch KeepAlive is not
AFAICT and despite the name, Fetch KeepAlive is not related to TCP Keep-Alive. TCP connections are handled by browsers without exposing control to web pages.
Default value for KeepAlive
- KeepAlive: false => This means that events are dropped if a browser tab is closed.
- KeepAlive: true => Events have a smaller size limit, but will be sent even if users navigate away or close tab.
Could we do both?
I believe KeepAlive: true would be the best in most cases, and KeepAlive: false if we know the event is going to be large (the client/transport can estimate it).