This looks like issue related to local host.In house team not having the permission to create local host url, hence adding the respective label for it to triage further.

Thank You!

You mentioned "localhost" in the bug title. Are you trying to map "localhost" to an IP other than 127.0.0.1? If so, this is unsupported. See https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06 for an explanation, and  issue 683213  for the recent bugfix that might have caused you to start seeing this behavior. If that's what happened, please respond here so I can close the bug.

If that's not the issue, please provide a net-internals log following the instructions at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.

Thank you mge!

It was because of Chrome's hosts check of localhost mappings. After using local instead of localhost, it worked. It's still an awkward workaround, which i would prefer not to do... I can't see the security necessity for this, since no other browsers do it, and probably will never do.

But thank you anyway, at least i can keep developing on Chrome for the momment.

Localhost is considered a magical, secure origin, even for HTTP (non-HTTPS) requests.  Hence, we bypass DNS lookups for it.

But you couldn't make it available as a flag you could turn off inside Chrome settings? This way you would still secure those who unintentionally navigate to a localhost which is mapped to an external ip, and you allow those who knows what they are doing to keep working as they like. I mean, this is a Google team, not Apple, should be more customizable and advanced.

The preference in Chrome is to minimize the number of settings (compare chrome://settings in Chrome to the thousands of settings in FireFox), and this comes nowhere near the general utility needed for that.  The idea is that fewer settings both makes settings easier to use, and there are fewer combinations of settings that can cause things to break badly.  Agree or disagree, changing that philosophy is above my pay grade.

I agree, never mess it up, so no user can find head or tails in the settings. But to be honest, your chrome://flags/ is a clustermess, and you once had the option to disable this functionality inside of there before. Can't see why one line would make a difference in such a big list. This is also not a list which the average user access.

It's not the UI that's the problem, but the underlying logic, and making sure it works with everything else.  about:flags is supposed to be for features under development, that aren't production ready yet (i.e., targeted solely at Chrome developers actively working on a feature, not power users).  The practice hasn't quite matched the theory there.

Okay, makes sense. Well thanks for the quick replies once again! :)