2 calls to a 302-redirecting script are shown in network panel, if the target is NOT within the same origin
Reported by
chaolbvb...@gmail.com,
Sep 6 2016
|
|||||||||||
Issue description
Chrome Version : 52.0.2743.116 (Official Build) (64-bit)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: OK
Firefox: OK
IE: OK
What steps will reproduce the problem?
(1) do an ajax request to a script A.
(2) script A will redirect to another resource B with a 302 status code
(3a) resource B is within the same origin
(3b) resource B is NOT within the same origin
What is the expected result?
in both cases 3a and 3b the redirecting script and the final resource and only those two should be visible in the network panel
What happens instead?
if resource B in NOT within the same origin, two calls to the redirecting script are visible, with two different initiators, one being the script itself
Please provide any additional information below. Attach a screenshot if
possible.
Although two requests a shown in the network panel, luckily only one call to the script is performed.
,
Sep 6 2016
Not sure if this is a general CORS issue, or something XHR-specific. A repro would be great, as it could also be expected behavior, given the Javascript.
,
Sep 6 2016
You can find a repro here: http://chaolbvbiens.net/redirect.html
,
Sep 14 2016
Thank you for providing more feedback. Adding requester "elawrence@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 14 2016
Confirmed in 55.0.2860.0 Network-level monitoring shows one request hits the network. chrome://net-internals tracing shows only one request: URL_REQUEST http://chaolbvbiens.net/redirect.php?sameOrigin=false Chrome Network panel shows two entries, including one spurious entry with a bogus initiator. As such, I believe this is only a quirk of how the DevTools Network panel collects data, so changing Component accordingly.
,
Sep 14 2016
,
Sep 15 2016
,
Sep 27 2016
+toyoshim, we could use your input on this: It appears that we are allowing both ResourceFetcher::willFollowRedirect and RawResource::willFollowRedirect to dispatch the same request. Here's a simple stack trace of where the stacks diverge: debug::StackTrace::StackTrace() InspectorNetworkAgent::willSendRequestInternal() InspectorNetworkAgent::willSendRequest() InspectorInstrumentation::willSendRequest() FrameFetchContext::dispatchWillSendRequest() ResourceFetcher::willSendRequest() ResourceFetcher::startLoad() ResourceFetcher::requestResource() RawResource::fetch() DocumentThreadableLoader::loadRequest() DocumentThreadableLoader::makeCrossOriginAccessRequest() DocumentThreadableLoader::redirectReceived() RawResource::willFollowRedirect() ResourceLoader::willFollowRedirect() WebURLLoaderImpl::Context::OnReceivedRedirect() WebURLLoaderImpl::RequestPeerImpl::OnReceivedRedirect() ResourceDispatcher::OnReceivedRedirect() And: debug::StackTrace::StackTrace() InspectorNetworkAgent::willSendRequestInternal() InspectorNetworkAgent::willSendRequest() InspectorInstrumentation::willSendRequest() FrameFetchContext::dispatchWillSendRequest() ResourceFetcher::willSendRequest() ResourceFetcher::willFollowRedirect() ResourceLoader::willFollowRedirect() WebURLLoaderImpl::Context::OnReceivedRedirect() WebURLLoaderImpl::RequestPeerImpl::OnReceivedRedirect() ResourceDispatcher::OnReceivedRedirect() If you would like I could maybe explain it a bit better offline if you need more clarification.
,
Jul 24 2017
Issue 747065 has been merged into this issue.
,
Jul 24 2017
crbug.com/644238 has an easy repro case.
,
Dec 13 2017
@toyoshim: over to you per allada's request, could you clarify?
,
Dec 13 2017
,
Dec 19 2017
I think this is a possible issue. In the DocumentThreadableLoader, we create another resource load request on a cross-origin redirect because we need to modify HTTP request headers, but existing redirect interface does not allow it. This problem should be solved once my out-of-blink CORS works are finished.
,
Dec 3
What is the status of this issue?
,
Dec 5
I confirmed that the issue was fixed if OOR-CORS is enabled.
,
Dec 5
Thanks! |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by elawrence@chromium.org
, Sep 6 2016