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

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 <sof@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 <sof@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

Received on Monday, 18 August 2014 07:22:51 UTC