- From: Jatinder Mann <jmann@microsoft.com>
- Date: Tue, 9 Apr 2013 23:53:06 +0000
- To: James Simonsen <simonjam@chromium.org>, "Deng, Pan" <pan.deng@intel.com>
- CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <0d8542c8287d4a60ae08b8131d9ec1fe@BY2PR03MB074.namprd03.prod.outlook.com>
Based on the current spec text, seems like the behavior we had agreed upon in the past was that if any of the redirects are not of the same origin as the current document and if any of them do not pass the timing allow check algorithm, we will zero out the redirectStart and redirectEnd attributes. I think the idea here is that either we give the true redirection time or we give a zero'd out time. If we give a partial value, it may not be clear that this isn't the true redirection time. Thanks, Jatinder From: James Simonsen [mailto:simonjam@chromium.org] Sent: Tuesday, April 9, 2013 1:50 PM To: Deng, Pan Cc: Jatinder Mann; public-web-perf@w3.org Subject: Re: [Resource Timing]Statements about cross-origin redirect should be more clearly Sounds good to me. The important thing is that each redirect must allow the document's origin. The only question is what to do if R2 disallows and the rest allow. Should we include R3 in redirectStart/End or just leave those fields permanently zeroed out? Is there any risk in revealing where in the chain the cross-origin redirect may have occurred? James On Mon, Apr 1, 2013 at 2:10 AM, Deng, Pan <pan.deng@intel.com<mailto:pan.deng@intel.com>> wrote: Retrieve this thread as it is cold. I think the proposed clarification will clear the usage for browser/web developer, and it won't change intended meaning of Resource Timing spec, any comments? :) Thanks Pan From: Deng, Pan [mailto:pan.deng@intel.com<mailto:pan.deng@intel.com>] Sent: Monday, February 04, 2013 5:12 PM To: public-web-perf@w3.org<mailto:public-web-perf@w3.org> Subject: [Resource Timing]Statements about cross-origin redirect should be more clearly In Section 4.3 about 'redirectStart', 'redirectEnd', CR doc[1]says: "if any of the redirects are not from the same origin as the current document, and the Timing-Allow-Origin HTTP response header rules are met, this attribute must return ......" What is the meaning of "Timing-Allow-Origin HTTP response header rules are met"? Consider scenario: doc D req R1 -> R2 -> R3 -> R4. ( "->" : redirect, R4 is the final resource) It may imply: a), Any Ri's response timing-allowing-origin D. (apply to any Ri and doc D) b), R1's response timing-allow-origin D, R2's response timing allow R1... till R4's response timing allow R3. (apply to redirect chain) >From timing-allow-check algorithm in [2], it can be inferred that a) is the right one. However, Processing Model 3.19a of [1] says "If the current resource and the resource that is redirected to are not from the same origin, set redirectStart and redirectEnd to 0". Here redirectStart/End should be reset once there is a cross-origin redirect, without Timing-Allow-Origin consideration at all, is it a typo here? To make the spec more clearly, I suggest a small modification to avoid the inconsistency: Statement in section 4.3 can be modified to "if any of the redirects are not from the same origin as the current document, and the Timing-Allow-Origin HTTP response header rules are met by current document", and Processing Model 3.19a can be modified to "current resource and the document are not from same origin, and Timing-Allow-Origin HTTP response header rule is not met by the document, set redirectStart and redirectEnd to 0". Any idea? Thanks :) Pan [1] http://www.w3.org/TR/2012/CR-resource-timing-20120522/ [2] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#timing-allow-check
Received on Tuesday, 9 April 2013 23:53:58 UTC