Re: [NavigationTiming] incorrect description for requestStart

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