Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 461808 http://127.0.0.1 shouldn't be treated as Mixed Content from Apps / Extensions
Starred by 3 users Reported by sirdarck...@gmail.com, Feb 25 2015 Back to list
Status: Fixed
Owner: ----
Closed: Feb 23
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
Version: 41.0.2272.65
OS: Chrome OS

What steps will reproduce the problem?
1. Open https://code.google.com/
2. Exec with(new XMLHttpRequest)open('get', 'http://127.0.0.1'),send();

What is the expected output? What do you see instead?
I expect the request to succeed.

I see a warning about mixed content.

jschuh@ told me this was a bug, and that 127.0.0.1 was supposed to be treated as not-mixed-content.

Please use labels and text to provide additional information.

 
Full error, in case it matters

Mixed Content: The page at 'https://code.google.com/p/chromium/issues/detail?id=461808&thanks=461808&ts=1424874511' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://127.0.0.1/'. This request has been blocked; the content must be served over HTTPS.VM257:2 (anonymous function)VM256:847 InjectedScript._evaluateOnVM256:780 InjectedScript._evaluateAndWrapVM256:646 InjectedScript.evaluate
Comment 2 by mkwst@chromium.org, Feb 25 2015
The spec disagrees with jschuh@, but maybe we should make an exception for localhost.

That said, I don't think we should be making it easier to request internal resources from public webpages (see issue #378566 for discussion on that topic). What's the use-case this behavior is blocking?
Comment 3 by jsc...@chromium.org, Feb 25 2015
I think there's a bit of confusion about what I said. So, to be clear, we do not want to make it easier to request internal/local resources from the public web. To the contrary, we want to block it unless there's explicit opt-in.

That stated, we do want to treat localhost and file URLs as having a secure transport, because they don't expose data to the network and are not vulnerable to MitM (ignoring local network shares, but that's really a burden for the OS).
yeah, fwiw the full context was about chrome extensions not being able to talk to localhost. I used code.google.com but I now realize it's not really the same.
Summary: http://127.0.0.1 shouldn't be treated as Mixed Content from Apps / Extensions (was: http://127.0.0.1 shouldn't be treated as Mixed Content)
Labels: -Cr-Blink Cr-Blink-SecurityFeature
Status: Fixed
We no longer consider `http://127.0.0.1` mixed content. We do aim to make it harder to talk to in the future, but MIX is the wrong place to do it.
Sign in to add a comment