Re: Cross Origin and Resource Timing

I think the Processing Model needs to be updated as well.  In addition 
to not zero'ing out responseEnd and duration, it should say "and go to 
step 20" instead of "and abort the following steps" so the resource ends 
up in the buffer.

- Nic


On 2/18/2012 5:23 AM, Zhiheng Wang wrote:
>    Done.
>
> cheers,
> Zhiheng
>
> On Sat, Feb 18, 2012 at 1:16 AM, Jatinder Mann <jmann@microsoft.com 
> <mailto:jmann@microsoft.com>> wrote:
>
>     I think we are all in agreement. Please update the Resource Timing
>     spec.
>
>     Thanks,
>
>     Jatinder
>
>     *From:*Zhiheng Wang [mailto:zhihengw@google.com
>     <mailto:zhihengw@google.com>]
>     *Sent:* Thursday, February 16, 2012 11:24 PM
>     *To:* James Simonsen
>     *Cc:* Jatinder Mann; Ricardo Oliveira; Tony Gentilcore
>     (tonyg@google.com <mailto:tonyg@google.com>); Alois Reitbauer;
>     public-web-perf@w3.org <mailto:public-web-perf@w3.org>
>
>
>     *Subject:* Re: Cross Origin and Resource Timing
>
>        I think the consensus of the WG was to keep the starting and
>     ending time just like we discuss here. The text in the
>
>     draft is some left-over from previous revisions: we used to have
>     "fetchEnd" in the x-origin case so zeroing out responseEnd
>
>     is fine. But later we removed fetchEnd from the spec...
>
>        If no objection, I will fix the the text and keep the value of
>     responseEnd.
>
>     cheers,
>
>     Zhiheng
>
>     On Fri, Feb 17, 2012 at 7:18 AM, James Simonsen
>     <simonjam@chromium.org <mailto:simonjam@chromium.org>> wrote:
>
>     I don't remember deciding to zero everything out. I'll have to dig
>     through the archives I guess. Can we use source control to see
>     when these changes went in?
>
>     My recollection and intent was to have startTime and duration
>     available, since you can basically get those with Javascript
>     timestamps. All of the other details would be zero. That should at
>     least make them useful on the timeline, but without exposing
>     anything that couldn't be seen before.
>
>     James
>
>     On Thu, Feb 16, 2012 at 10:02 AM, Jatinder Mann
>     <jmann@microsoft.com <mailto:jmann@microsoft.com>> wrote:
>
>     Adding James, Tony and Zhiheng, since they were involved in the
>     initial discussions.
>
>     If we want to give the total duration for cross origin resources,
>     we would update the processing model to not zero out responseEnd
>     and include the resource in the PerformanceResourceTiming buffer.
>     StartTime is already defined for cross origin resources in the
>     processing model.
>
>     Jatinder
>
>     *From:*Ricardo Oliveira [mailto:rvelosoo@gmail.com
>     <mailto:rvelosoo@gmail.com>]
>     *Sent:* Thursday, February 16, 2012 9:52 AM
>     *To:* Jatinder Mann
>     *Cc:* Alois Reitbauer; public-web-perf@w3.org
>     <mailto:public-web-perf@w3.org>
>     *Subject:* Re: Cross Origin and Resource Timing
>
>     I thought that was agreed already... Alois question is about how
>     to get the total time since the final timestamps are all zeroed
>
>     Cheers
>
>     --Ricardo
>
>     Thousandeyes.com <http://Thousandeyes.com>
>
>
>     Sent from my iPhone
>
>
>     On Feb 16, 2012, at 9:43 AM, Jatinder Mann <jmann@microsoft.com
>     <mailto:jmann@microsoft.com>> wrote:
>
>         Considering one is able to obtain this data in other ways, I’m
>         not opposed to providing the total duration but not the
>         detailed breakdown of a cross-origin resource. This will make
>         sure that the timeline makes sense and this API doesn’t omit
>         resources that the page does use. Thoughts from the working group?
>
>         *From:*Alois Reitbauer [mailto:alois.reitbauer@dynatrace.com]
>         <mailto:[mailto:alois.reitbauer@dynatrace.com]>
>         *Sent:* Thursday, February 16, 2012 2:27 AM
>         *To:* public-web-perf@w3.org <mailto:public-web-perf@w3.org>
>         *Subject:* RE: Cross Origin and Resource Timing
>
>         I am convinced that if we do not get an overall timing for
>         third party resources it has very hard to understand their
>         performance impact on the page. Our analysis shows that a lot
>         of today’s pages spend more than two thirds of their time with
>         Third Party resources.
>
>         Getting these timings is also possible today. It requires a
>         couple of hacks;  but works. We implemented it for our own
>         monitoring, would however prefer if there is a better way to
>         do this.  Following the principle that we expose the same
>         information that people get today this information therefore
>         can be exposed without adding an additional security hole. It
>         will just be easier to access it and collecting this
>         information and have less effect on page performance as it
>         might have today.
>
>         // Alois
>
>         *From:*Jatinder Mann [mailto:jmann@microsoft.com]
>         <mailto:[mailto:jmann@microsoft.com]>
>         *Sent:* Wednesday, February 15, 2012 8:54 PM
>         *To:* Alois Reitbauer; public-web-perf@w3.org
>         <mailto:public-web-perf@w3.org>
>         *Subject:* RE: Cross Origin and Resource Timing
>
>         Initially, I had thought that we had zero’d out the respondEnd
>         attribute in error in the cross-origin restrictions section
>         and that our intention was to give durations for even
>         cross-origin resources.
>
>         However, while looking at the Resource Timing Processing Model
>         in more detail, I see that we had added the following clause:
>
>         If the last non-redirected fetch
>         <http://www.w3.org/TR/html5/fetching-resources.html#fetch> of
>         the resource is not the same origin as the current document
>         and the Timing-Allow-Origin
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#timing-allow-origin>
>         HTTP response header does not apply, the user agent must set
>         redirectStart
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#redirect-start>,
>         redirectEnd
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#redirect-end>,
>         domainLookupStart
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#domainlookup-start>,
>         domainLookupEnd
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#domainlookup-end>,
>         connectStart
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#connect-start>,
>         connectEnd
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#connect-end>,
>         requestStart
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#request-start>,
>         responseStart
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#response-start>,
>         responseEnd
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#response-end>,
>         and duration
>         <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#duration-attribute>
>         to zero and abort the remaining steps.
>
>         Not only is the duration explicitly set to zero, but steps to
>         include this resource in the buffer are skipped. I believe the
>         motivation here was that cross-origin resources should be
>         explicitly not included in the PerformanceResourceTiming
>         buffer. However, if someone were to look at the entire
>         performance timeline, they could deduce that the gap was due
>         to a cross-origin resource.
>
>         An alternate proposal could be to provide the end to end time
>         (fetchStart to responseEnd), but zero out the individual
>         attributes.
>
>         Does the working group recall why we went with the former
>         approach?
>
>         Thanks,
>
>         Jatinder
>
>         *From:*Alois Reitbauer [mailto:alois.reitbauer@dynatrace.com]
>         <mailto:[mailto:alois.reitbauer@dynatrace.com]>
>         *Sent:* Wednesday, February 15, 2012 12:06 AM
>         *To:* public-web-perf@w3.org <mailto:public-web-perf@w3.org>
>         *Subject:* Cross Origin and Resource Timing
>
>         As far as I can remember the final decision was that for cross
>         origin resources which do not have the allow origin header set
>         no detailed timings but the total time to download the
>         resources is shown. I checked again with the latest version of
>         the spec and it says
>
>         , these attributes must be set to zero: redirectStart
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#redirect-start>,
>         redirectEnd
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#redirect-end>,
>         domainLookupStart
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#domainlookup-start>,
>         domainLookupEnd
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#domainlookup-end>,
>         connectStart
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#connect-start>,
>         connectEnd
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#connect-end>,
>         requestStart
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#request-start>,
>         responseStart
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#response-start>,
>         and responseEnd
>         <http://w3c-test.org/webperf/specs/ResourceTiming/#response-end>.
>
>         This would mean that one only gets the fetchStart time which
>         means that we only know when the download started but not when
>         it is finished.
>
>         Did I miss anything here?
>
>         // Alois
>
>