Re: [NavigationTiming] incorrect description for requestStart

   Thanks, Jatinder. Yes, please assign the AI to me.

cheers,
Zhiheng

On Thu, May 26, 2011 at 10:13 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  Zhiheng,
>
>
>
> We have reviewed the changes made to Navigation Timing. These changes look
> good. I have opened *ACTION-34 - Update Resource Timing spec with the same
> requestStart fix made in Navigation Timing spec* on you to make these
> changes to Resource Timing also.
>
>
>
> Thanks,
>
> Jatinder
>
>
>
> *From:* public-web-perf-request@w3.org [mailto:
> public-web-perf-request@w3.org] *On Behalf Of *Zhiheng Wang
> *Sent:* Tuesday, May 24, 2011 4:37 PM
> *To:* Jason Duell
> *Cc:* Christian Biesinger; public-web-perf
> *Subject:* 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
>
>
>
>
>
>
>