New issue
Advanced search Search tips

Issue 767167 link

Starred by 2 users
Status: Duplicate
Merged: issue 766091
Owner: ----
Closed: Sep 2017
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

SSL forced on local device domains

Reported by r...@weeverapps.com, Sep 20 2017 
Chrome Version: 63.0.3218.0 MacOS 10.12.6

Seems if you develop a web app locally using your own domain (e.g. add in the hostfile/use Gas Mask), Chrome forwards every request to HTTPS, not allowing an HTTP query.

Steps To Reproduce:
(1) Go to http://myfakedomain.dev
(2) Chrome changes this to https://myfakedomain.dev without even checking if there's a site there at that domain

Expected Result: Should have queried HTTP to see if something is there before rejecting.

Actual Result: Chrome changes protocol without testing

How frequently does this problem reproduce? Always, though it does not happen with http://localhost or http://*.local domains.

What is the impact to the user, and is there a workaround? If so, what is
it?

No work-around for domains as they are, other than to use a different browser for development of a site locally, or change your domains to .local.

Please provide any additional information below. Attach a screen shot or
log if possible.

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

Comment 1 by rda...@gmail.com, Sep 21 2017 

I can confirm that this also happens on Windows 10 with Version 63.0.3221.0 (Official Build) canary (32-bit).

I have lots of local Virtual Hosts set-up in WAMP that are entries in my hosts file, and Canary tries to redirect them all from HTTP to HTTPS.

The only way to stop it from doing this is to use either 'localhost' as the domain (which isn't suitable for my needs), or to use a locally bound IP address such as 192.168.0.1.

Comment 2 by davidben@chromium.org, Sep 21 2017

Mergedinto: 766091
Status: Duplicate (was: Unconfirmed)
You should use .test, not .dev. .dev is actually a real TLD these days. You should be using one of the TLDs described in RFC 2606 to avoid collisions with possible future domains:

                   .test
                .example
                .invalid
              .localhost

Those are reserved for testing and will not be turned into real TLDs.

Comment 3 by rda...@gmail.com, Sep 21 2017 

Good point. Surely it shouldn't matter though? I should be able to add an entry for google.com in my local hosts file if I want, and as long as there is something to serve it locally it should never try to go anywhere else.

Comment 4 by r...@weeverapps.com, Sep 22 2017 

I'm inclined to agree with the previous comment. If you wish to route any domain locally, regardless of its registration/TLD status, I don't see why the HTTP protocol should be skipped in favour of HTTPS. Could this not break some intranet setups?

Comment 5 by lgar...@chromium.org, Sep 25 2017 

> If you wish to route any domain locally, regardless of its registration/TLD status, I don't see why the HTTP protocol should be skipped in favour of HTTPS. Could this not break some intranet setups?

This is what .localhost is for.
It is still useful to support HSTS on localhost for testing, although we has  Issue 607881  (Blacklist HSTS for localhost).
►

Sign in to add a comment