[Webkit-unassigned] [Bug 103867] [Resource Timing] Record redirectStart & redirectEnd time and expose in resource timing entries

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jan 16 19:52:43 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=103867





--- Comment #12 from pdeng6 <pan.deng at intel.com>  2013-01-16 19:54:29 PST ---
(In reply to comment #11)
> (In reply to comment #10)
> > case 2: although Ri and its adjacent are not the same origin, Ri allow its prior 'timing', or allowed timing by its posterior.
> 
> We don't consider Timing-Allow-Origin during redirects. Its purpose is to allow a specific main document to view timing data for a specific subresource, not to share timing data across the redirect chain.
> 
> > if above right, I would like to store redirect response chain(in CachedResource? I'm not sure how to store in m_initiatorMap of CachedResourceLoader) then feed it to  addResourceTiming(...). in addResourceTiming, pass in the correct values for startTime and redirectEnd in the constructor.
> 
> I don't think you need all that. Just reset the initiationTime when there's a cross-origin redirect.

I don't quite understand this, 

in section4.3, startTime should be initiationTime(redirectStart) when if all the redirects or equivalent are from the same origin as the current document or the Timing-Allow-Origin HTTP response header rules are met.
now, as my understand, my case2 in comment #10 should be: 
case 2: although Ri and Doc D are not the same origin, response of Ri allow-timing by Doc D's origin.
then startTime should be initiationTime(first) or final resource fetch time(last), then why we reset the initiationTime? startTime in processing model never changed after 3.2.

what is more puzzled me is in processing model 3.19a, redirectStart is reset according to "current resource and the resource that is redirected to"

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list