Proxy stopped working on Mac

[zaidhuda]

Hotel is accessible at http://localhost:2000/ but not on http://hotel.localhost/ even though automatic proxy has been set to http://localhost:2000/proxy.pac.

macOS Mojave
Google Chrome Version 71.0.3578.98 (Official Build) (64-bit)

[samanthabaita]

I have the same Google Chrome version (71.0.3578.98) and the proxy doesn't work after the last update. Try using a different browser and hotel should work (with Firefox works fine).

[jonalvarezz]

I can confirm that it breaks down with Chrome. Safari/Firefox working fine

[melMass]

This should be notified in the readme for now.

[johndouthat]

I'm having the same issue with Chrome 71.0.3578.98. Going to hotel.localhost returns ERR_CONNECTION_REFUSED. Chrome Canary 73.0.3660.0 is also experiencing the same problem. Safari and Firefox are working fine. Chrome 60 and 70 on the same Mac works fine. So something happened between Chrome versions 70 and 71 to make it not work with the Hotel proxy.

[johndouthat]

I set "tld" to "foobar" in hotel.conf and restarted hotel and Chrome, and now hotel.foobar works in Chrome 71. So maybe Chrome just doesn't like the .localhost TLD?

I found an article about changes in Chrome 71 and looked for anything regarding proxies. It mentions CVE-2018-18358, whose description is

Lack of special casing of localhost in WPAD files in Google Chrome prior to 71.0.3578.80 allowed an attacker on the local network segment to proxy resources on localhost via a crafted WPAD file.

Here's a write-up with some more depth:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1707

There is a chromium issue, but I do not have permissions to read it:
https://bugs.chromium.org/p/chromium/issues/detail?id=899126

I'm not certain, but maybe it's related.

[johndouthat]

I think I found the commit in Chrome for version 71:
chromium/chromium@0e2a57d
which is a partial cherry pick of this commit, which has a more detailed commit message:
chromium/chromium@da790f9

• localhost names (as determined by net::IsLocalhost) now implicitly bypass the proxy

See ProxyBypassRules::MatchesImplicitRules to see that *.localhost is an implicit rule.

See line 4014 and 4068 of the unit test to see that they explicitly test to ensure foo.localhost bypasses the proxy when using a PAC script

The commit message says that you can either manually configure the proxy settings (i.e. not use a PAC script) or use "<-loopback>" proxy bypass rule to reverse this behavior, but I'm not sure how to do either of those things yet.

Of course, just switching to *.foobar also works, but is not ideal

[erikthered]

I'm seeing the same issue with Firefox 65.0 on macOS 10.14.2. Setting another tld in hotel.conf works as expected.