Restore setting windows host to localhost

[KyleAMathews]

No description provided.

[KyleAMathews]

aka like this #171

[gatsbybot]

Deploy preview ready!

Built with commit f705915

https://deploy-preview-2983--gatsbygram.netlify.com

[gatsbybot]

Deploy preview ready!

Built with commit f705915

https://deploy-preview-2983--using-drupal.netlify.com

[gatsbybot]

Deploy preview ready!

Built with commit 56d0e39

https://deploy-preview-2983--gatsbygram.netlify.com

[gatsbybot]

Deploy preview ready!

Built with commit 56d0e39

https://deploy-preview-2983--using-drupal.netlify.com

[rdela]

Looks good so far plain gatsby new, gatsby develop prints http://0.0.0.0:8000, Safari 11.0.1 and Firefox 59.0a1 console clear, Chrome beta 63.0.3239.52 and canary 64.0.3274.0 both have 2 errors, all work with HMR:

Uncaught Error: The error you provided does not contain a stack trace.
    at parseError (index.js:2369)
    at getStackFrames (index.js:2262)
    at crashWithFrames (index.js:1926)
    at index.js:1944
    at rejectionHandler (index.js:2040)

0.0.0.0/:1 Uncaught (in promise) DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV).
Promise rejected (async) |   |  
-- | -- | --
  | (anonymous) | @ | app.js:28
  | Promise resolved (async) |   |  
  | ./.cache/app.js | @ | app.js:15
  | __webpack_require__ | @ | bootstrap bc5a377…:555
  | fn | @ | bootstrap bc5a377…:86
  | 0 | @ | index.js:176
  | __webpack_require__ | @ | bootstrap bc5a377…:555
  | ./node_modules/ansi-html/index.js.module.exports | @ | bootstrap bc5a377…:578
  | (anonymous) | @ | bootstrap bc5a377…:578

[rdela]

gatsby develop --host localhost works, prints http://localhost:8000/ which works with HMR but does not print an On Your Network: address, presumably because setting --host means I want to use that as my local network testing address.

[rdela]

Same for setting gatsby develop --host [machineName].local HMR works!
True for local machine and others on network (phones etc), also tested HMR using phone local On Your Network: IP with plain gatsby develop, working with HMR.

On the Chrome errors, expanded shortlink:
Chromium‎ > ‎Chromium Security‎ > ‎Prefer Secure Origins For Powerful New Features

“Secure origins” are origins that match at least one of the following (scheme, host, port) patterns: 
(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —) 
This list may be incomplete, and may need to be changed. Please discuss! 

A bug to define “secure transport” in Blink/Chromium: https://code.google.com/p/chromium/issues/detail?id=362214
For Example 
For example, Chrome is going to make Service Workers available only to secure origins, because it provides the origin with a new, higher degree of control over a user's interactions with the origin over an extended period of time, and because it gives the origin some control over the user's device as a background task.

Consider the damage that could occur if a user downloaded a service worker script that had been tampered with because they got it over a MITM’d or spoofed cafe wifi connection. What should have been a nice offline document editor could be turned into a long-lived spambot, or maybe even a surveillance bot. If the script can only run when delivered via authenticated, integrity-protected transport like HTTPS, that particular risk is significantly mitigated. 

…and indeed setting gatsby develop --host localhost and using http://localhost:8000 makes the errors go away, as does gatsby develop --host 127.0.0.1 and using http://127.0.0.1:8000/. So maybe there is merit to the default on non-Windows being localhost or 127.0.0.1?

I told Shannon during our interview one of the things I am in awe of is how available you have made yourself to the evolving community, and that having an easier start could help trim noise in here and in Discord/Spectrum etc. So getting rid of these errors by defaulting to localhost or 127.0.0.1 on Mac/BSD/Linux/UNIX as well and making people set 0.0.0.0 if they want that might be preferable in that regard at least.

Chromium folks do say:

This list may be incomplete, and may need to be changed. Please discuss!

So we could rally to have 0.0.0.0 included I suppose unless that has some awful security implication or something like that to disqualify it.

[abumalick]

I have CORS problem with hot reloading on mac with chrome 62.0.3202.94

resolved by using gatsby -H localhost (I didn't find documentation about that param though)

I use last version of gatsby

[benjaminhoffman]

I can confirm that I too have the CORS problems + broken HMR using gatsby develop. Running gatsby develop --host localhost fixes this for me.

• mac Sierra; 10.12.6
• chrome 62.0.3202.94
• "gatsby": "^1.9.50"