W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2013

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

From: Arvind Jain <arvind@google.com>
Date: Tue, 3 Dec 2013 09:56:58 -0800
Message-ID: <CAOYaDdPAP_+wEEfdkY=GG0NBotom_7hyzF9R4+LEpc5v-qj0LA@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
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

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.
Received on Tuesday, 3 December 2013 17:57:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC