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

I think we should first focus on defining the behavior for Beacon. We can
figure out later if we should retrofit that into XHR.

It seems like defining size limits/queue limit is o
Arvind


On Tue, Dec 3, 2013 at 9:46 AM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> 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.
>
>