WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
85025
[Resource Timing] Report redirect time for resources
https://bugs.webkit.org/show_bug.cgi?id=85025
Summary
[Resource Timing] Report redirect time for resources
James Simonsen
Reported
2012-04-26 19:24:42 PDT
Redirect time is always 0. This should report the correct values. We had to add some code to MainResourceLoader to track redirects while fetching the main resource for Navigation Timing. We'll have to do the same for ResourceLoader. We also need to ensure that the redirect times reported honor the same-origin policy noted in the spec. They should be zeroed out if there are any cross-origin redirects.
Attachments
Patch
(15.42 KB, patch)
2012-07-31 07:37 PDT
,
pdeng6
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
pdeng6
Comment 1
2012-07-31 07:37:13 PDT
Created
attachment 155530
[details]
Patch
Gyuyoung Kim
Comment 2
2012-07-31 07:44:24 PDT
Comment on
attachment 155530
[details]
Patch
Attachment 155530
[details]
did not pass efl-ews (efl): Output:
http://queues.webkit.org/results/13403191
WebKit Review Bot
Comment 3
2012-07-31 07:44:31 PDT
Comment on
attachment 155530
[details]
Patch
Attachment 155530
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/13384980
Build Bot
Comment 4
2012-07-31 07:50:50 PDT
Comment on
attachment 155530
[details]
Patch
Attachment 155530
[details]
did not pass mac-ews (mac): Output:
http://queues.webkit.org/results/13389698
Early Warning System Bot
Comment 5
2012-07-31 07:52:20 PDT
Comment on
attachment 155530
[details]
Patch
Attachment 155530
[details]
did not pass qt-ews (qt): Output:
http://queues.webkit.org/results/13401400
Build Bot
Comment 6
2012-07-31 07:53:10 PDT
Comment on
attachment 155530
[details]
Patch
Attachment 155530
[details]
did not pass win-ews (win): Output:
http://queues.webkit.org/results/13401397
Early Warning System Bot
Comment 7
2012-07-31 08:11:40 PDT
Comment on
attachment 155530
[details]
Patch
Attachment 155530
[details]
did not pass qt-wk2-ews (qt): Output:
http://queues.webkit.org/results/13392742
James Simonsen
Comment 8
2012-07-31 11:31:03 PDT
You'll want to base this on the patch in
https://bugs.webkit.org/show_bug.cgi?id=84883
We don't want to populate the buffer from the loaders, because they don't have access to the initiator. So we're implementing this a level up. Also, we need to support the Timing-Allow-Origin header. And test cases.
pdeng6
Comment 9
2012-08-01 06:01:07 PDT
(In reply to
comment #8
)
> You'll want to base this on the patch in
https://bugs.webkit.org/show_bug.cgi?id=84883
> > We don't want to populate the buffer from the loaders, because they don't have access to the initiator. So we're implementing this a level up. > > Also, we need to support the Timing-Allow-Origin header. And test cases.
Thanks for quick response; I can help Timing-Allow-Origin issue and test cases:) About populating performance entries from kinds of CachedResourceClient, I feel it will take more engineering effort and a little confused, another issue is several entries will be populated when one time fetched resource is feed to several CachedResourceClients(W3C spec recommends one entry). Is it possible we expose initiator informantion by virtual functions from CachedResourceClient => CachedResource => SubResourceLoader? Then we can have centralized control of timing info, redirect etc in loader.
James Simonsen
Comment 10
2012-08-01 20:27:57 PDT
(In reply to
comment #9
)
> About populating performance entries from kinds of CachedResourceClient, I feel it will take more engineering effort and a little confused, another issue is several entries will be populated when one time fetched resource is feed to several CachedResourceClients(W3C spec recommends one entry).
That's a good point.
> Is it possible we expose initiator informantion by virtual functions from CachedResourceClient => CachedResource => SubResourceLoader? Then we can have centralized control of timing info, redirect etc in loader.
I'm worried about the case where the first element is removed from the document, but another element requests the same resource. According to the spec, the original element should still be reported as the initiator. In the above design, we can't rely on the original element still being a client. One option would be to pass the initiator in to the CachedResource and the first one to construct the object in the MemoryCache becomes the initiator. However, I got the sense that this was not desirable, because of layering. We don't want a lot of DOM knowledge in loader/. Maybe this one is okay though? Another alternative would be to use more of an observer design, like Inspector. We could just note when an element requests a URL and when the loaders make a request, redirect, and finish. Resource Timing would keep track of the state on its end. That also has the benefit of not needing an extra parameter everywhere CachedResource is used. Other ideas?
Adam Barth
Comment 11
2012-08-02 08:02:52 PDT
I'm going to defer to Nate on these questions.
pdeng6
Comment 12
2012-09-06 07:53:21 PDT
@Nate, how do you think about this?
Anders Carlsson
Comment 13
2014-02-05 10:59:06 PST
Comment on
attachment 155530
[details]
Patch Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug