Re: [Beacon] Required Beacon-Age: handling.

requestTime should be set to the time immediately after sendBeacon()
is called. So it should be before the actual Fetch is performed. The
actual Fetch may be performed quite a bit later (e.g. if the user
agent decides to delay the transmission).

It was not the intention to let Beacon-Age serve an alternate purpose.
But please check this thread that lists why we added the header:
http://lists.w3.org/Archives/Public/public-web-perf/2014May/0028.html

I suppose it is ok to make the header optional i.e. its absence is
considered equivalent to Beacon-Age = 0.

Any opinions?


On Sun, Aug 17, 2014 at 10:18 AM, Sigbjørn Finne <sof@opera.com> wrote:
> Hi,
>
> we're currently considering adding support for Beacon-Age: to Blink's
> implementation of navigator.sendBeacon() [1], which has generated some
> questions surrounding this late addition:
>
>  - When exactly is
> https://w3c.github.io/web-performance/specs/Beacon/Overview.html#sec-processing-model
> (step 11) supposed to be done & requestTime sampled? When the Fetch
> request is handed to the next layer down in the network stack, at the
> last possible opportunity (post-DNS lookups, ...) before the bits go
> across the wire, .. ? Or are we free to sample that at whatever time
> is convenient to the implementation?
>
>  - Related to the previous, if an implementation doesn't provide
> support for delaying transmission (or retrying), but is eager, the age
> value will always be zero. Rather than transmit a header that conveys
> no useful information (e.g., "Beacon-Age: 0"), would it be allowed to
> leave out the header altogether? Both the Blink[1] and Gecko[2]
> implementations do not currently support request delaying.
>
> One might argue that Beacon-Age: serves an alternate purpose (that of
> indicating "Beacon-ness" of the request), but perhaps that should be
> relayed separately. It seems like we're currently promising a bit more
> than what we can keep/communicate wrt Beacon-Age. Thoughts, comments?
>
> --sigbjorn
>
> 1: https://code.google.com/p/chromium/issues/detail?id=398167
> 2: https://bugzilla.mozilla.org/show_bug.cgi?id=1045222
>

Received on Monday, 18 August 2014 02:03:38 UTC