Bug 145717

Summary:

It's impossible to detect that XMLHttpRequest is blocked by mixed content blocking

Product:

WebKit

Reporter:

Alexey Proskuryakov <ap>

Component:

WebCore Misc.

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

beidson, bfulgham, cdumez, dbates, mcatanzaro, oliver, wilander, youennf

Priority:

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

See Also:

https://bugs.webkit.org/show_bug.cgi?id=140940
https://bugs.webkit.org/show_bug.cgi?id=145718

Bug Depends on:

Bug Blocks:

140625

Attachments:

Description	Flags
test	none

Alexey Proskuryakov

Reported 2015-06-05 16:19:53 PDT

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.

Attachments
test (2.45 KB, patch) 2016-05-10 14:34 PDT, Alex Christensen	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Alexey Proskuryakov

Comment 1 2015-06-05 16:28:01 PDT

security/mixedContent/resources/insecure-xhr-in-main-frame-window.html will be one such test to run once i update it in bug 145718.

Michael Catanzaro

Comment 2 2015-06-08 08:10:50 PDT

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

Alexey Proskuryakov

Comment 3 2015-06-08 09:55:58 PDT

IIRC, Firefox raised an exception from send() in my testing.

Michael Catanzaro

Comment 4 2015-11-10 17:30:48 PST

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."

Alex Christensen

Comment 5 2016-05-10 14:34:48 PDT

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. 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.

Michael Catanzaro

Comment 6 2016-05-10 16:14:25 PDT

(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.

youenn fablet

Comment 7 2016-08-03 01:54:19 PDT

(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

Michael Catanzaro

Comment 8 2018-01-08 17:09:32 PST

I think this bug is a duplicate of bug #146706. *** This bug has been marked as a duplicate of bug 146706 ***

Note You need to log in before you can comment on or make changes to this bug.