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

(forking thread)

On Fri, Nov 22, 2013 at 6:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Nov 22, 2013 at 5:19 PM, Jatinder Mann <jmann@microsoft.com>
> wrote:
> > The WG discussed whether we should apply a limit to the number of beacons
> > that can be sent or the size of the beacons sent. While we had initially
> > considered a limit of 10KBs, after some discussion, we saw real world
> > examples of much larger data being sent. We eventually decided to not
> limit
> > the size of the beacons, as limits set now may not feel rational years
> from
> > now. We opened ACTION-114 - Update beacon spec to have no limits, no
> retry
> > logic, no batching, post is the only method to track this.
>

I hesitate to re-open this can of worms, but... If there are no enforced
limits, no batching, no retries, and so on, then do we need an entire new
interface for beacon? These restrictions were the primary reason (to me) as
to why we needed/wanted a separate interface. Also, I'm not sure why given
no restrictions on any of the above we then limit it to POST only -- seems
inconsistent.

Assuming we drop all of the above restrictions, then the only new feature
here is that the request can be "detached" from the parent page - i.e. if
the page then transitions to onunload / tab is closed, then the request
does not hold up the event and is not cancelled. With that in mind, this is
more simply expressed as:

var xhr = new XMLHttpRequest();
xhr.detach = true; // or some such...
...
xhr.open('GET', '/path');

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.
- if parent page is gone by the time XHR completes, callbacks are not
fired.. otherwise, callbacks fire as a regular XHR would.

In short, detach could be a flag that provides a simple insurance policy:
this request should not block onunload and it should continue past
onunload. However, if request completes after the parent page has been
unloaded, no callbacks are fired... This also implicitly means no retries,
etc.

An upside of such mechanism would be that it is trivial to retrofit on top
of millions of currently deployed beacons which rely on XHR: just add
'detach=true' and you're done.

 ig