matthew-andrews / isomorphic-fetch

Isomorphic WHATWG Fetch API, for Node & Browserify
MIT License
6.95k stars 288 forks source link

Error: only absolute urls are supported #76

Closed hoangdo94 closed 8 years ago

gocreating commented 8 years ago

Same problem

hoangdo94 commented 8 years ago

@gocreating I have already solved the problem of mine. It relates to an issue of my api server configs, not this package's issue :)

gocreating commented 8 years ago

@hoangdo94 It seems that for client side there is no need to give domain name to fetch api, but it is necessary for server side.

matthew-andrews commented 8 years ago

yes, this is correct. i'm not sure it's possible for server side code to guess the correct hostname…?

ctxhou commented 8 years ago

So is there any solution for this?

gocreating commented 8 years ago

@ctxhou You can handle it by yourself.

Here is my solution (but I have already switched to superagent):

import superagent from 'superagent';
import getPort from '../../server/utils/getPort';
const BASE = process.env.BROWSER? '': `http://localhost:${getPort()}`;

function formatUrl(path) {
  return `${BASE}${path}`;
}

const request = superagent[method](formatUrl(path));

You can reference the complete file in my boilerplate.

ctxhou commented 8 years ago

@gocreating

cool, it's one of the solution. Thanks!

btw, why you want to change to use superagent?

gocreating commented 8 years ago

@ctxhou Fetch API doesn't support hooks and download/upload progress. So I cannot implement ajax progress bar. That's just my personal reason.

matthewadams commented 7 years ago

FYI, just connecting the dots here. This issue relates to https://github.com/bitinn/node-fetch/issues/75 & https://github.com/swagger-api/swagger-js/issues/1044.

dijs commented 7 years ago

I don't see why this was closed, it looks like node-fetch fixed the bug in 1.5.3 according to this https://github.com/bitinn/node-fetch/issues/43... So shouldn't this library update its node-fetch dependency?

wyqydsyq commented 7 years ago

I am also running into this issue. I am running this inside a Docker container, my graphql endpoint is on another Docker container in the same docker-compose swarm, I am trying to use the Docker's internal DNS hostname for the graphql container (core_graphql) which Docker's network layer transparently resolves to the correct address, however the Javascript code from this library (or one of it's dependencies) is throwing this error, preventing me from using this in a clean manner.

If using non-absolute URLs would pose issues server-side, then an exception should be thrown when the connection actually fails, instead of just throwing an exception before even attempting to use the provided URL to connect.

gilles-yvetot commented 6 years ago

What I did to solve that was to install node-fetch as a dependency of my project. The current version is 1.7.3 and the requirement for isomorphic-fetch is ^1.0.1 so you will have the latest version installed in your project.

NB: you do need to reinstall all your packages though

razvangherghina commented 6 years ago

Probably just missing some environment variable. This message is the same if you pass undefined as url to node-fetch

nukeop commented 6 years ago

I noticed this problem when supplying ipv6.

lemoustachiste commented 6 years ago

This also happens when you are trying to get a relative path is ../../my/path/to/myfile.json. This is supported in browsers (tested on Firefox, Chrome and Safari).

My issue is in testing, tests fail because of the above error, which is annoying because now I have a distinction between the browser and the node environment running the tests.

This is the stack trace beyond my code:

      at node_modules/node-fetch/index.js:54:10
      at new Fetch (node_modules/node-fetch/index.js:49:9)
      at Fetch (node_modules/node-fetch/index.js:37:10)
      at Object.<anonymous>.module.exports (node_modules/isomorphic-fetch/fetch-npm-node.js:8:19)

I understand this is not an issue directly related with isomorphic-fetch, but rather with node-fetch, but I'd like to voice this case anyway.