incorrect CORS violation warning and missing request chain for redirected sendBeacon call |
|||
Issue descriptionVersion: 51.0.2704.106 (64-bit) OS: OSX 10.11.5 What steps will reproduce the problem? (1) Open http://output.jsbin.com/suxagi/latest/quiet with devtool console + network panel (2) Console shows a "redirect at origin X has been blocked from loading by CORS policy" (3) Inspect the network trace (or WPT) and notice that the requests are (correctly) allowed to continue: http://www.webpagetest.org/result/160617_9Y_113E/1/details/ What is the expected output? DevTools should not issue the warning and should show the redirect chain in Net panel. What do you see instead? A single request and a warning in console. --- Related: https://github.com/w3c/beacon/pull/33
,
Jul 18 2016
sigbjorn, I think this may be yours. We're saying the redirect has been blocked, but it's not being blocked. :) However some of our network instrumentation is lost in this case.
,
Jul 25 2016
Yes, not failing hard enough - can fix. But the sendBeacon() to http://bit.ly/28QzPVZ in that testcase comes back with a 301 without any CORS headers afaict, so it is right to fail. Well, "fail", currently.
,
Jul 25 2016
sigbjornf: note that we've amended the spec to clarify the desired behavior [1]. The behavior we have in Chrome today (follow redirects) is correct, modulo some mimeType checks. [1] https://github.com/w3c/beacon/pull/33
,
Jul 25 2016
That's a substantial change, thanks for the pointer.
,
Jul 27 2016
I'm rather confused by https://github.com/w3c/beacon/pull/34 and https://github.com/w3c/beacon/pull/34/commits/8a6fbdca25115aa5a66c32cfc37d4882384b3398 , as it seems to flip non-Blob sendBeacon()s to being "cors", whereas https://github.com/w3c/beacon/pull/33 made those payloads be "no-cors". Is that change really intentional? I don't see the flip in behavior clearly motivated in all the discussions, but perhaps I've overlooked something.
,
Jul 27 2016
Ah, never mind, I wasn't looking at the latest https://fetch.spec.whatwg.org/#concept-bodyinit-extract -- mimeType will be set as expected for all payloads here.
,
Jul 27 2016
,
Jul 27 2016
sigbjornf: nice! On a quick pass, I think you're most of the way there to also address crbug.com/490015 -- any chance you could take a look at that one too?
,
Jul 27 2016
I don't think it is close to addressing that one properly; moving CORS handling out of the renderer would be.
,
Jul 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3fe79278480bcf6aea4172056d5b8beb18aeb5a9 commit 3fe79278480bcf6aea4172056d5b8beb18aeb5a9 Author: sigbjornf <sigbjornf@opera.com> Date: Thu Jul 28 13:22:41 2016 Update and fix sendBeacon() redirect behavior. Refresh the implementation to follow the specification changes in https://github.com/w3c/beacon/pull/33 https://github.com/w3c/beacon/pull/34 In particular, correctly flag a CORS-disallowed redirect as not to be followed by WebURLLoader. R= BUG= 628762 Review-Url: https://codereview.chromium.org/2177383006 Cr-Commit-Position: refs/heads/master@{#408380} [add] https://crrev.com/3fe79278480bcf6aea4172056d5b8beb18aeb5a9/third_party/WebKit/LayoutTests/http/tests/navigation/beacon-cross-origin-redirect-blob-expected.txt [add] https://crrev.com/3fe79278480bcf6aea4172056d5b8beb18aeb5a9/third_party/WebKit/LayoutTests/http/tests/navigation/beacon-cross-origin-redirect-blob.html [modify] https://crrev.com/3fe79278480bcf6aea4172056d5b8beb18aeb5a9/third_party/WebKit/LayoutTests/http/tests/navigation/beacon-cross-origin-redirect-expected.txt [modify] https://crrev.com/3fe79278480bcf6aea4172056d5b8beb18aeb5a9/third_party/WebKit/Source/core/loader/BeaconLoader.cpp [modify] https://crrev.com/3fe79278480bcf6aea4172056d5b8beb18aeb5a9/third_party/WebKit/Source/core/loader/BeaconLoader.h
,
Jul 28 2016
|
|||
►
Sign in to add a comment |
|||
Comment 1 by alph@chromium.org
, Jul 15 2016Status: Assigned (was: Untriaged)