Bug 145717 - It's impossible to detect that XMLHttpRequest is blocked by mixed content blocking
Summary: It's impossible to detect that XMLHttpRequest is blocked by mixed content blo...
Status: RESOLVED DUPLICATE of bug 146706
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 140625
  Show dependency treegraph
 
Reported: 2015-06-05 16:19 PDT by Alexey Proskuryakov
Modified: 2018-01-08 17:09 PST (History)
8 users (show)

See Also:


Attachments
test (2.45 KB, patch)
2016-05-10 14:34 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 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.
Comment 1 Alexey Proskuryakov 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.
Comment 2 Michael Catanzaro 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
Comment 3 Alexey Proskuryakov 2015-06-08 09:55:58 PDT
IIRC, Firefox raised an exception from send() in my testing.
Comment 4 Michael Catanzaro 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."
Comment 5 Alex Christensen 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.
Comment 6 Michael Catanzaro 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.
Comment 7 youenn fablet 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
Comment 8 Michael Catanzaro 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 ***