- From: Sigbjørn Finne <sof@opera.com>
- Date: Sun, 17 Aug 2014 19:18:08 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Cc: Adam Barth <abarth@chromium.org>, David Benjamin <davidben@chromium.org>
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 Sunday, 17 August 2014 17:18:36 UTC