Re: [NavigationTiming] incorrect description for requestStart

(Pardon me if this is a resend)

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

Received on Friday, 20 May 2011 06:56:39 UTC