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

Re: [Beacon] spec feedback + few suggestions

From: Chase Douglas <chase@newrelic.com>
Date: Wed, 6 Nov 2013 16:24:08 -0800
Message-ID: <CAKNWE6GzwHUmnTEJDe5fmv6R8G+HdVTRtnFA91jMFZOVtbpfEQ@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: "Austin, Daniel" <daaustin@paypal.com>, Ilya Grigorik <igrigorik@google.com>, Jonas Sicking <jonas@sicking.cc>, public-web-perf <public-web-perf@w3.org>
> I think we need to close on how we want to deal with failures, see mail
> thread [3]. Currently, the spec doesn’t go into the expected details on
> what to do if the beacon has failed to be sent or received for whatever
> reason. I personally rather we keep this behavior as implementation details
> and let the quality of implementation determine how often it will retry.
> However, it may make sense to put in some recommendations in the spec so we
> have interoperability. As Luke mentions, if one UA always sends the
> analytics by aggressively retrying but another doesn’t, the analytics data
> may be skewed, which may hurt the adoption of this method.

I think there should be some way for beacons to give some flow control
hints, ie a 503 status code with an optional "Retry-After" header that
should be honored by the UA. The UA may need to drop the data if it can't
hold on to it for that long, but oh well. I can imagine scenarios where a
beacon service goes down but load balancers stand in and send out 503s to
give the beacon service some time to come back up. Some data may be lost,
but hopefully much of the data could still come through on later retrys.

Perhaps this could also be a mechanism to ensure that UAs aren't too
aggresive in retries. If you know you won't be back up for 5 minutes, then
just tell UAs to wait that long.
Received on Thursday, 7 November 2013 00:24:36 UTC

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