Re: [NavigationTiming] incorrect description for requestStart

   FYI, the WD is now updated to make more sense out of the http cache
operations.

    1) Section 4.2, skip mentioning the http cache checking. It only makes
sense for requestStart to include
the checking of http cache if it's a cache hit.
    2) In processing model step 8, if it's an http cache hit, go to the step
of recording requestStart directly and
leave domain lookup and connection time as fetchStart.

cheers,
Zhiheng

On Fri, May 20, 2011 at 3:31 PM, Zhiheng Wang <zhihengw@google.com> wrote:

>
>
> On Thu, May 19, 2011 at 5:49 PM, Jason Duell <jduell@mozilla.com> wrote:
>
>> I'm also a bit confused by which/when timings should be set in the case of
>> a cache hit from the regular HTTP cache.  The spec notes that
>>
>> "Checking and retrieving contents from the HTTP cache [RFC 2616] is part
>> of the fetching process. It's covered by the requestStart, responseStart and
>> responseEnd attributes."
>>
>> Looking at steps 8-15 in the processing model for an HTTP cache hit:
>> -  step 9: at least for Mozilla, no DNS lookup is required to look for a
>> cache hit, so goto step 11
>> - step 11: makes it sound like we should be recording connectionStart/End
>> for a cache hit, which doesn't make much sense?
>>
>
>    great catch. Given that step 7 already set domain and connection related
> value to the same as fetchStart,
> it might be sufficient to modify step 11 as the following?
>
>    "If no transport connection is used to fetch the resource, go to step
> 13. If a persistent transport connection is used
> to fetch the resource, <the rest of the paragraph>".
>
>    An alternative is to modify step 8 to include http cache, i.e.,
>   " If the resource is fetched from the relevant application cache or HTTP
> cache or local resources, go to step 13."
> But I would like to see if this works fine with other user agents. Nic and
> Tony, any thought?
>
> cheers,
> Zhiheng
>
>
>> - step 13: I assume we set 'requestStart' just before we start looking at
>> the HTTP cache?
>> - step 14/15: seem to map sensibly onto first/last bytes of reply serviced
>> from cache.
>>
>> I'd propose we drop the connectionStart/End timing for cache hits, and
>> generally make the language clearer about what happens in the processing
>> model in the cache hit case.
>>
>> Jason Duell
>> Mozilla
>>
>>
>> On 05/19/2011 05:37 PM, Christian Biesinger wrote:
>>
>>> On Thu, May 19, 2011 at 5:33 PM, Christian Biesinger
>>> <cbiesinger@gmail.com>  wrote:
>>>
>>>> Hi,
>>>>
>>>> I just noticed a bug in the description for requestStart (Thanks
>>>> jduell):
>>>>
>>>>> This attribute must return the time immediately before the user agent
>>>>> starts requesting the current document. It is set prior to checking HTTP
>>>>> cache.
>>>>>
>>>>  From what I remember from the discussions and from the timeline below,
>>>> the "HTTP cache" sentence should be removed here, because this
>>>> attribute refers to the time immediately before the UA starts
>>>> write()ing to the socket. Otherwise, this would be identical to
>>>> fetchStart (which does have similar cache wording).
>>>>
>>> Also, can we clarify what "local ressources" are? Probably things like
>>> file:///?
>>>
>>> -christian
>>>
>>
>>
>>
>>
>