Re: [beacon] no limits, no retry, no batching, post only

On Mon, Dec 2, 2013 at 7:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> > var xhr = new XMLHttpRequest();
> > xhr.detach = true; // or some such...
> > ...
> > xhr.open('GET', '/path');
>
> I always felt that the main argument for not using the XHR syntax is
> that the XHR syntax sucks. And most of it is there in order to provide
> progress and result notifications, which I think we should avoid.
>

Regardless of how pretty it is, it is well understood and is already in use
by all the major vendors.. As such, I think the adoption delta is actually
smaller with XHR than with a brand new API.


> > In theory, this could provide following semantics:
> > - marking request as "detach" forces it to be async (i.e. can't do sync
> XHR
> > with detach=true)
> > - detach is functionally equivalent to XHR, callbacks and all.
>
> I explicitly do not want to provide any callbacks. That will limit the
> UAs ability to be smart about when the beacon is sent. I.e. the more
> information about when a beacon is sent that we expose, the larger the
> risk that pages will break as implementations change when the beacon
> is sent in order to save battery.


So, my proposal is to simply ignore any/all callbacks *if* the parent page
is gone:
- You fire a regular XHR with detach = true
- If the request completes while the host page is alive, your callbacks are
invoked
- If the host page is gone then no callbacks are executed (e.g. UA sends
headers + payload and then moves on)

This is effectively the behavior that you get today if you fire an async
XHR within the unload handler: it's a race condition between request being
emitted and it being cancelled.. in either case, unless you have a *very
slow* onunload handler, your callbacks never fire. Effectively, all this
does is allows the request to "complete" (the headers and body to be sent),
without it being cancelled by the UA when the page is being unloaded. As a
bonus, this is useful beyond just analytics beacons.