Den 18.08.2014 09:05, skreiv Arvind Jain:
Got it. Given how we wrote it, it would be before the Fetch is
initiated. So it would be before the request is sent to the network
stack.
Thanks much for clarifying. For implementations that don't delay
initiation (I know of none that do, but perhaps there are), this would
amount to "Beacon-Age: 0" for all practical purposes. Which brings up
the second question raised initially - what benefit does this bring?
--sigbjorn
On Sun, Aug 17, 2014 at 11:39 PM, Sigbjorn Finne <s...@opera.com> wrote:
Den 18.08.2014 08:14, skreiv Arvind Jain:
#11 is left to the user agent. In the usual case, it is hopefully soon
after step 10, but it can de delayed. Is it what you are asking?
It's in that area. So a UA is allowed to sample the time ("current time") at
any point after it decides to go ahead with the Beacon request that
sendBeacon() initiated, and there being no assumption that any/all
client-side&measurable delays have been performed when it does so?
--sigbjorn
On Sun, Aug 17, 2014 at 10:12 PM, Sigbjorn Finne <s...@opera.com> wrote:
Den 18.08.2014 04:03, skreiv Arvind Jain:
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).
That makes sense, what about the other end of the interval that the age
value captures, when is it assumed sampled, i.e., when is step 11
performed?
(That was what I was referring to, sorry about confusing the spec
naming.)
--sigbjorn
