Suppose the page below is loaded from https://127.0.100.1. The page makes an XMLHttpRequest to http://127.0.100.2. This seems like mixed content: The page is loaded over a secure connection and a resource is loaded over an insecure connection. Mixed content should be blocked by the browser. Yet, the page below works just fine.* Why does it work: Why isn't the request blocked?
Update: Going beyond the accepted answer, browsers can be configured to block mixed content for such addresses.
* Wireshark confirms browsers aren't loading the resource over a secure connection.
<html>
<body>
<img id="dst"/>
<script>
let xhr = new XMLHttpRequest();
xhr.open('get', 'http://127.0.100.2/img.jpg');
xhr.responseType = 'blob';
xhr.onload = function(){
document.getElementById('dst').src = URL.createObjectURL(xhr.response);
}
xhr.send();
</script>
</body>
</html>
Suppose the page below is loaded from https://127.0.100.1. The page makes an XMLHttpRequest to http://127.0.100.2. This seems like mixed content: The page is loaded over a secure connection and a resource is loaded over an insecure connection. Mixed content should be blocked by the browser. Yet, the page below works just fine.* Why does it work: Why isn't the request blocked?
Update: Going beyond the accepted answer, browsers can be configured to block mixed content for such addresses.
* Wireshark confirms browsers aren't loading the resource over a secure connection.
<html>
<body>
<img id="dst"/>
<script>
let xhr = new XMLHttpRequest();
xhr.open('get', 'http://127.0.100.2/img.jpg');
xhr.responseType = 'blob';
xhr.onload = function(){
document.getElementById('dst').src = URL.createObjectURL(xhr.response);
}
xhr.send();
</script>
</body>
</html>
- @sideshowbarker Your answer seems right. a priori authenticated URL meaning We know a priori that a request to a particular URL...will be delivered in a way that mitigates the risks of interception and modifications which includes URLs from a potentially trustworthy URL, where A potentially trustworthy URL includes one whose origin is a potentially trustworthy origin and A potentially trustworthy origin is one which a user agent can generally trust as delivering data securely, including when a origin’s host ponent matches one of the CIDR notations 127.0.0.0/8 or ::1/128 – user2768 Commented Feb 28, 2020 at 10:21
- This behaviour makes testing rather problematic! @sideshowbarker Is there a reasonable way to test for such behaviour when running websites on localhost? – user2768 Commented Feb 28, 2020 at 10:23
- 1 Can be more specific about what you mean by “way to test for such behaviour"? I’m guessing you don’t mean, a way to test that a host is in the 127.0.0.0 - 127.255.255.255 range (because that seems easily testable). So maybe you mean, is there a way to test whether the URL is considered a secure context or not? If so, no, the specifications and the platform don’t define any API for browsers to expose for doing any kind of testing for that? Or if that’s not what you mean, then please clarify further. – sideshowbarker ♦ Commented Feb 28, 2020 at 10:33
- @sideshowbarker I should have been clearer: How can I change my testing environment to see mixed content being blocked? – user2768 Commented Feb 28, 2020 at 10:37
- 1 I think you can’t change your testing environment to see mixed content being blocked — at least not in the way I assume you mean. It’s not observable from frontend JavaScript code. Basically all you can do is something like what the test at wpt.live/mixed-content/imageset.https.sub.html does. Otherwise, from outside the browser, you might be able to do more using Selenium/WebDriver. – sideshowbarker ♦ Commented Feb 28, 2020 at 11:22
1 Answer
Reset to default 10 +50http://127.0.100.2/img.jpg isn’t considered mixed content because the Mixed Content spec defines it as a special case of an a priori authenticated URL, due to it being in the range 127.0.0.0 - 127.255.255.255 (that is, a host with the CIDR notation 127.0.0.0/8), which per the Secure Contexts spec is defined as a secure context — even if the protocol isn’t https.
The same goes for http://localhost/img.jpg or http://foo.localhost/img.jpg