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