145717 2015-06-05 16:19:53 -0700 It's impossible to detect that XMLHttpRequest is blocked by mixed content blocking 2018-01-08 17:09:32 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 146706 https://bugs.webkit.org/show_bug.cgi?id=140940 https://bugs.webkit.org/show_bug.cgi?id=145718 P2 Normal --- 140625 1 ap webkit-unassigned beidson bfulgham cdumez dbates mcatanzaro oliver wilander youennf oldest_to_newest 1100005 0 ap 2015-06-05 16:19:53 -0700 When mixed content blocking is enabled in WebKit, mixed content XMLHttpRequests just appear to stall - they forever remain in readyState 1, and don't get any final events. I suspect that they likely leak at some level too. Steps to reproduce: 1. Put any simple XMLHttpRequest test case into LayoutTests/tests/http that loads from http://127.0.0.1:8000 2. Run this command (it essentially runs the server for us, as run-webkit-httpd doesn't support https): run-webkit-tests LayoutTests/http/tests/xmlhttprequest/readystatechange.html --repeat 100000 3. Open your test using https, observe that the load stalls. 1100009 1 ap 2015-06-05 16:28:01 -0700 security/mixedContent/resources/insecure-xhr-in-main-frame-window.html will be one such test to run once i update it in bug 145718. 1100364 2 mcatanzaro 2015-06-08 08:10:50 -0700 Note that the WIP mixed content spec strongly implies that we should fire the XHR's onerror event when we block it, but it doesn't actually tell us to do so: it seems to presume that we're *already* doing it [1]. I couldn't find a specification for that anywhere, but is seems like the Right Thing. I have a patch for this in bug #140793, but the patch is old and not completely right: it causes two mixed content warnings to be emitted for just one XHR. I think the spurious one is coming from the CachedResourceLoader. Unfortunately I don't plan to work on this more in the near future. [1] http://www.w3.org/TR/mixed-content/#websockets-integration 1100393 3 ap 2015-06-08 09:55:58 -0700 IIRC, Firefox raised an exception from send() in my testing. 1141010 4 mcatanzaro 2015-11-10 17:30:48 -0800 I wonder if this was fixed by bug #146706. TODO: test it out! (In reply to comment #3) > IIRC, Firefox raised an exception from send() in my testing. To be clear: the candidate recommendation strongly implies we should fire onerror and not throw an exception: "These changes together mean that we’ll no longer throw a SecurityError exception directly upon constructing a WebSocket object, but will instead rely upon blocking the connection and triggering the fail the WebSocket connection algorithm, which developers can catch by hooking a WebSocket object’s onerror handler. This is consistent with the behavior of XMLHttpRequest, EventSource, and Fetch." 1191660 5 278532 achristensen 2016-05-10 14:34:48 -0700 Created attachment 278532 test While playing with HSTS, I came across this. We call the onreadystatechange with readyState == 1 then readyState == 4 and status 0, then call the onerror. Chrome and Firefox just call onreadystatechange with readyState == 1 then stop. I think our behavior is more correct, but I don't see it specified anywhere. 1191713 6 mcatanzaro 2016-05-10 16:14:25 -0700 (In reply to comment #5) > Created attachment 278532 [details] > test > > While playing with HSTS, I came across this. We call the onreadystatechange > with readyState == 1 then readyState == 4 and status 0, then call the > onerror. This seems like desirable behavior, and it's still implied by the candidate recommendation (see comment #2) that's being developed by Chrome folks. Alex, I think this is a duplicate of bug #146706, which is now fixed; do you agree? > Chrome and Firefox just call onreadystatechange with readyState > == 1 then stop. I think our behavior is more correct, but I don't see it > specified anywhere. I guess this was our behavior prior to bug #146706. The old behavior broke YouTube for us with adblocker enabled; YouTube would wait for a horrible timeout before starting to play videos, because it thought the ad was still loading. 1216857 7 youennf 2016-08-03 01:54:19 -0700 (In reply to comment #4) > I wonder if this was fixed by bug #146706. TODO: test it out! > > (In reply to comment #3) > > IIRC, Firefox raised an exception from send() in my testing. > > To be clear: the candidate recommendation strongly implies we should fire > onerror and not throw an exception: > > "These changes together mean that we’ll no longer throw a SecurityError > exception directly upon constructing a WebSocket object, but will instead > rely upon blocking the connection and triggering the fail the WebSocket > connection algorithm, which developers can catch by hooking a WebSocket > object’s onerror handler. This is consistent with the behavior of > XMLHttpRequest, EventSource, and Fetch." This is described in https://fetch.spec.whatwg.org/#main-fetch, xhr being based on fetch in xhr.spec.whatwg.org 1387006 8 mcatanzaro 2018-01-08 17:09:32 -0800 I think this bug is a duplicate of bug #146706. *** This bug has been marked as a duplicate of bug 146706 *** 278532 2016-05-10 14:34:48 -0700 2016-05-10 14:35:33 -0700 test test.diff text/plain 2504 achristensen SW5kZXg6IExheW91dFRlc3RzL2h0dHAvdGVzdHMvc2VjdXJpdHkvaHN0cy9iYXNpYy1leHBlY3Rl ZC50eHQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9zZWN1cml0eS9oc3Rz L2Jhc2ljLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2h0dHAvdGVz dHMvc2VjdXJpdHkvaHN0cy9iYXNpYy1leHBlY3RlZC50eHQJKHdvcmtpbmcgY29weSkKQEAgLTAs MCArMSw2IEBACitBTEVSVDogeGhyIHJlYWR5U3RhdGUgKDEpIHN0YXR1cyAoMCkgcmVzcG9uc2VU ZXh0ICgpCitDT05TT0xFIE1FU1NBR0U6IGxpbmUgMTY6IFtibG9ja2VkXSBUaGUgcGFnZSBhdCBo dHRwczovLzEyNy4wLjAuMTo4NDQzL3NlY3VyaXR5L2hzdHMvcmVzb3VyY2VzL2Jhc2ljLWZpbmlz aC5waHAgd2FzIG5vdCBhbGxvd2VkIHRvIGRpc3BsYXkgaW5zZWN1cmUgY29udGVudCBmcm9tIGh0 dHA6Ly8xMjcuMC4wLjE6ODQ0My9zZWN1cml0eS9oc3RzL3Jlc291cmNlcy9ibG9ja2VkLnR4dC4K KworQUxFUlQ6IHhociByZWFkeVN0YXRlICg0KSBzdGF0dXMgKDApIHJlc3BvbnNlVGV4dCAoKQor QUxFUlQ6IHhociBvbmVycm9yIGNhbGxlZAorCkluZGV4OiBMYXlvdXRUZXN0cy9odHRwL3Rlc3Rz L3NlY3VyaXR5L2hzdHMvYmFzaWMuaHRtbAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9odHRw L3Rlc3RzL3NlY3VyaXR5L2hzdHMvYmFzaWMuaHRtbAkocmV2aXNpb24gMCkKKysrIExheW91dFRl c3RzL2h0dHAvdGVzdHMvc2VjdXJpdHkvaHN0cy9iYXNpYy5odG1sCSh3b3JraW5nIGNvcHkpCkBA IC0wLDAgKzEsMTQgQEAKKzxzY3JpcHQ+CitpZiAod2luZG93LnRlc3RSdW5uZXIpIHsKKyAgICB0 ZXN0UnVubmVyLmR1bXBBc1RleHQoKTsKKyAgICAvL3Rlc3RSdW5uZXIuZHVtcEZyYW1lTG9hZENh bGxiYWNrcygpOworICAgIC8vdGVzdFJ1bm5lci5kdW1wUG9saWN5RGVsZWdhdGVDYWxsYmFja3Mo KTsKKyAgICAvL3Rlc3RSdW5uZXIuZHVtcFJlc291cmNlTG9hZENhbGxiYWNrcygpOworICAgIHRl c3RSdW5uZXIud2FpdFVudGlsRG9uZSgpOworfQorCitmdW5jdGlvbiBzdGFydCgpIHsKKyAgICB3 aW5kb3cubG9jYXRpb24gPSAiaHR0cHM6Ly8xMjcuMC4wLjE6ODQ0My9zZWN1cml0eS9oc3RzL3Jl c291cmNlcy9iYXNpYy1maW5pc2gucGhwIjsKK30KKzwvc2NyaXB0PgorPGJvZHkgb25sb2FkPSJz dGFydCgpIiAvPgpJbmRleDogTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9zZWN1cml0eS9oc3RzL3Jl c291cmNlcy9iYXNpYy1maW5pc2gucGhwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2h0dHAv dGVzdHMvc2VjdXJpdHkvaHN0cy9yZXNvdXJjZXMvYmFzaWMtZmluaXNoLnBocAkocmV2aXNpb24g MCkKKysrIExheW91dFRlc3RzL2h0dHAvdGVzdHMvc2VjdXJpdHkvaHN0cy9yZXNvdXJjZXMvYmFz aWMtZmluaXNoLnBocAkod29ya2luZyBjb3B5KQpAQCAtMCwwICsxLDE2IEBACis8IS0tIDw/cGhw IGhlYWRlcignU3RyaWN0LVRyYW5zcG9ydC1TZWN1cml0eTogbWF4LWFnZT0xMDAwMDAwMCcpOyA/ PiAtLT4KKzxzY3JpcHQ+CisKK3ZhciB4aHIgPSBuZXcgWE1MSHR0cFJlcXVlc3QoKTsKK3hoci5v bnJlYWR5c3RhdGVjaGFuZ2UgPSBmdW5jdGlvbiAoKSB7CisJYWxlcnQoInhociByZWFkeVN0YXRl ICgiICsgeGhyLnJlYWR5U3RhdGUgKyAiKSBzdGF0dXMgKCIgKyB4aHIuc3RhdHVzICsgIikgcmVz cG9uc2VUZXh0ICgiICsgeGhyLnJlc3BvbnNlVGV4dCArICIpIik7Cit9OworeGhyLm9uZXJyb3Ig PSBmdW5jdGlvbiAoKSB7CisgICAgYWxlcnQoInhociBvbmVycm9yIGNhbGxlZCIpOworCWlmICh3 aW5kb3cudGVzdFJ1bm5lcikKKwkJdGVzdFJ1bm5lci5ub3RpZnlEb25lKCk7Cit9Cit4aHIub3Bl bignR0VUJywgJ2h0dHA6Ly8xMjcuMC4wLjE6ODQ0My9zZWN1cml0eS9oc3RzL3Jlc291cmNlcy9i bG9ja2VkLnR4dCcpOworeGhyLnNlbmQoKTsKKworPC9zY3JpcHQ+CkluZGV4OiBMYXlvdXRUZXN0 cy9odHRwL3Rlc3RzL3NlY3VyaXR5L2hzdHMvcmVzb3VyY2VzL2Jsb2NrZWQudHh0Cj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIExheW91dFRlc3RzL2h0dHAvdGVzdHMvc2VjdXJpdHkvaHN0cy9yZXNvdXJjZXMvYmxv Y2tlZC50eHQJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0cy9odHRwL3Rlc3RzL3NlY3VyaXR5 L2hzdHMvcmVzb3VyY2VzL2Jsb2NrZWQudHh0CSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEgQEAK K1RoaXMgc2hvdWxkIGJlIGJsb2NrZWQuClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQo=