Gatsby: Specifying 0.0.0.0 as host does not load webfonts/images

Created on 3 Jul 2018  路  13Comments  路  Source: gatsbyjs/gatsby

This is also noted in #561

Description

If you run gatsby using gatsby develop -H 0.0.0.0 you are able to access the gatsby site on localhost or on your local network, however, webfonts and images are not loaded.

Steps to reproduce

Run the command gatsby develop -H 0.0.0.0 with some images and webfonts in use on your page.

Expected result

Resources should load properly

Actual result

No resources are loaded.

A workaround to this is specifying your computers actual local ip address and then accessing it that way.

E.g. gatsby develop -H 192.168.1.8

This prevents you from being able to access the site from the localhost name though, you have to manually type in your ip address.

If you inspect an image when you run gatsby with 0.0.0.0 as the host you can see that http://0.0.0.0:8000/ is prepended. This is the problem. If you remove that prepended host and just leave the path relative then the resource will load correctly.

Environment

System:
OS: Windows 10
CPU: x64 Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
Binaries:
Yarn: 1.7.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 5.6.0 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: 41.16299.15.0

help wanted question or discussion

Most helpful comment

Please keep this open. Per @wardpeet "it's probably valuable to fix this". Thanks!

All 13 comments

Can you provide a demo repo that reproduces this?

I tried gatsby develop -H 0.0.0.0 with the image-processing example and the images were loaded in the page. I'm on macOS instead of Windows though.

Are you using webfonts from Google Fonts or Typekit?

If you use a premium webfont host, like Typekit and others that are paid, you have to whitelist the domains for the kit. That includes production domains and development environments. So, you could add local.example.com or localhost etc

This is a windows issue not anything Gatsby can fix. Windows apparently doesnt resolve 0.0.0.0 to localhost like other OSs do. See this older issue https://github.com/gatsbyjs/gatsby/pull/171

I'm not sure there's an alternate to selecting the actual network address? Did our docs suggest to you to use 0.0.0.0? If so, we should add a note that this doesn't work on Windows.

@KyleAMathews No, I wasn't following documentation that suggested this.


I looked into it more since I was pretty sure I had seen this behavior before. Create-React-App uses 0.0.0.0 as the default and there aren't any problems, even on Windows, so I wanted to see what they did.

It looks like they solve this by making the default host 0.0.0.0. Then, when the development server is bound to 0.0.0.0 or :: (ipv4 or ipv6), localhost is used throughout the application.

If Gatsby is hardcoding the resource fetching to a path based off the hostname then we could solve this issue by having code which sets the path prefix to the server's public ip address instead. This would only happen if the ip address was not specified by the user to still allow for fancier configurations (see example below)

You can see an example here in this block, where Create-React-App swaps 0.0.0.0/:: out for localhost (we want to do public ip):


  const isUnspecifiedHost = host === '0.0.0.0' || host === '::';
  let prettyHost, lanUrlForConfig, lanUrlForTerminal;
  if (isUnspecifiedHost) {
    prettyHost = 'localhost';
    try {
      // This can only return an IPv4 address
      lanUrlForConfig = address.ip();
      if (lanUrlForConfig) {
        // Check if the address is a private ip
        // https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces
        if (
          /^10[.]|^172[.](1[6-9]|2[0-9]|3[0-1])[.]|^192[.]168[.]/.test(
            lanUrlForConfig
          )
        ) {
          // Address is private, format it for later use
          lanUrlForTerminal = prettyPrintUrl(lanUrlForConfig);
        } else {
          // Address is not private, so we will discard it
          lanUrlForConfig = undefined;
        }
      }
    } catch (_e) {
      // ignored
    }
  } else {
    prettyHost = host;
  }
  const localUrlForTerminal = prettyPrintUrl(prettyHost);
  const localUrlForBrowser = formatUrl(prettyHost);
  return {
    lanUrlForConfig,
    lanUrlForTerminal,
    localUrlForTerminal,
    localUrlForBrowser,
  };
}

We are having this problem as well. We have to set the host to 0.0.0.0 for docker but that doesn't work on Windows. Does anyone know of a workaround?

I am getting this problem on Ubuntu. All images are prepended with http://0.0.0.0:8000/.

Now I'm seeing the problem more clearly. Even if I run on gatsby develop without the -H, the images are all prefixed with the host: http://localhost/ in this case. Which is different from how gatsby runs in production with no host prepended to the images. For example on production I might see <img src="/static/timeline_img_1-651fb39b31727c16f5fe15bbe012add8.png">. Is there a reason that local development can't use relative URLs for images like production does?

Just noticed this on fonts: http://0.0.0.0:8000/static/some-font-bd67f25d9c25994ffde79d2a81b85a66.woff
My issues is that I'm running VM and then accessing page on local network, but obviosly that doesn't work because 0.0.0.0 doesn't exist for that client.

Is it possible to remove host from url? So that it should be only /static/some-font-bd67f25d9c25994ffde79d2a81b85a66.woff?

Also, getting this error each time HMR should happen:

Unhandled Rejection (Error): Manifest request to http://0.0.0.0:8000/462da770009dbf9b7d1e.hot-update.json timed out.

It's probably valueable to fix this, sadly this issues is going to be low prio on our list so if anyone wants to take it, feel free to do so.

You can find code that create-react-app is using here:
https://github.com/facebook/create-react-app/blob/706b319633a59e1e0d58f1bb957e9d30d172f9d8/packages/react-dev-utils/WebpackDevServerUtils.js#L54

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 馃挭馃挏

Please keep this open. Per @wardpeet "it's probably valuable to fix this". Thanks!

This I believe was resolved in #11227. Reopen this if not

Was this page helpful?
0 / 5 - 0 ratings

Related issues

signalwerk picture signalwerk  路  3Comments

kalinchernev picture kalinchernev  路  3Comments

benstr picture benstr  路  3Comments

brandonmp picture brandonmp  路  3Comments

dustinhorton picture dustinhorton  路  3Comments