So this is kind of interesting, and I had a look at the spec.

> The data parameter is the BodyInit data that is to be transmitted.

However I couldn't find any information in the Spec itself about the size of the data until it said this :

> The user agent imposes limits on the amount of data that can be sent via this API: [...] If the amount of data to be queued exceeds the user agent limit [...] , this method returns false; a return value of true implies the browser has queued the data for transfer. However, since the actual data transfer happens asynchronously, this method does not provide any information whether the data transfer has succeeded or not.

Am I missing something or does this seem as unreliable as any other method for achieving this ?

How about, and this might be a crazy idea, letting the users leave without annoying them ?

▲

lifthrasiir 5 days ago | parent [-]

Technically speaking a conforming agent can ignore every single sendBeacon call by always returning false. And that's a point: beacons are opportunistic asynchronous requests. You can't do anything when they error anyway, so they should be regarded as hints that agents may or may not honor.

▲

bilekas 5 days ago | parent [-]

Okay so it's basically just a baked in implementation of what people did already but instead of using onUnload they have more visibility into the client context. Seems dirty in a way, the agent could basically internally call the same thing and send any data to their own server on every page?

For example, firefox, If they wanted, could record all your browsing history without notifying you? For any bad actor this seems like an amazing attack point.

	▲	swiftcoder 5 days ago \| parent [-]
		Firefox could do that anyway, whether or not this API exists. Browser implementors need to be at least moderately trustworthy, or no one will use them.