当请求实际上没有失败时,获取“ TypeError: 挂起失败”

我在我的 React 应用程序中使用 获取 API。应用程序部署在服务器上,并且工作正常。我测试了很多次。但是,突然应用程序停止工作,我不知道为什么。问题在于,当我发送一个 get请求时,我从服务器接收到一个有效的响应,而且获取 API 捕获一个异常并显示 TypeError: Failed to fetch。我甚至没有对代码做任何修改,这就是所有 React 组件的问题所在。

我得到了一个合理的回答:

enter image description here

但同时也得到了这个错误:

enter image description here

fetch(url)
.then(res => res.json())
.then(data => {
// do something with data
})
.catch(rejected => {
console.log(rejected);
});

当我删除凭据: “ include”时,它可以在本地主机上工作,但不能在服务器上工作。

我尝试了 StackOverflow 和 GitHub 提供的所有解决方案,但它们都不适合我。

463505 次浏览

Note that there is an unrelated issue in your code but that could bite you later: you should return res.json() or you will not catch any error occurring in JSON parsing or your own function processing data.

Back to your error: You cannot have a TypeError: failed to fetch with a successful request. You probably have another request (check your "network" panel to see all of them) that breaks and causes this error to be logged. Also, maybe check "Preserve log" to be sure the panel is not cleared by any indelicate redirection. Sometimes I happen to have a persistent "console" panel, and a cleared "network" panel that leads me to have error in console which is actually unrelated to the visible requests. You should check that.

Or you (but that would be vicious) actually have a hardcoded console.log('TypeError: failed to fetch') in your final .catch ;) and the error is in reality in your .then() but it's hard to believe.

This could be an issue with the response you are receiving from the backend. If it was working fine on the server then the problem could be within the response headers.

Check the value of Access-Control-Allow-Origin in the response headers. Usually fetch API will throw fail to fetch even after receiving a response when the response headers' Access-Control-Allow-Origin and the origin of request won't match.

I know it's a relative old post but, I would like to share what worked for me: I've simply input "http://" before "localhost" in the url. Hope it helps somebody.

If your are invoking fetch on a localhost server, use non-SSL unless you have a valid certificate for localhost. fetch will fail on an invalid or self signed certificate especially on localhost.

I understand this question might have a React-specific cause, but it shows up first in search results for "Typeerror: Failed to fetch" and I wanted to lay out all possible causes here.

The Fetch spec lists times when you throw a TypeError from the Fetch API: https://fetch.spec.whatwg.org/#fetch-api

Relevant passages as of January 2021 are below. These are excerpts from the text.

4.6 HTTP-network fetch

To perform an HTTP-network fetch using request with an optional credentials flag, run these steps:
...
16. Run these steps in parallel:
...
2. If aborted, then:
...
3. Otherwise, if stream is readable, error stream with a TypeError.

To append a name/value name/value pair to a Headers object (headers), run these steps:

  1. Normalize value.
  2. If name is not a name or value is not a value, then throw a TypeError.
  3. If headers’s guard is "immutable", then throw a TypeError.

Filling Headers object headers with a given object object:

To fill a Headers object headers with a given object object, run these steps:

  1. If object is a sequence, then for each header in object:
    1. If header does not contain exactly two items, then throw a TypeError.

Method steps sometimes throw TypeError:

The delete(name) method steps are:

  1. If name is not a name, then throw a TypeError.
  2. If this’s guard is "immutable", then throw a TypeError.

The get(name) method steps are:

  1. If name is not a name, then throw a TypeError.
  2. Return the result of getting name from this’s header list.

The has(name) method steps are:

  1. If name is not a name, then throw a TypeError.

The set(name, value) method steps are:

  1. Normalize value.
  2. If name is not a name or value is not a value, then throw a TypeError.
  3. If this’s guard is "immutable", then throw a TypeError.

To extract a body and a Content-Type value from object, with an optional boolean keepalive (default false), run these steps:
...
5. Switch on object:
...
ReadableStream
If keepalive is true, then throw a TypeError.
If object is disturbed or locked, then throw a TypeError.

In the section "Body mixin" if you are using FormData there are several ways to throw a TypeError. I haven't listed them here because it would make this answer very long. Relevant passages: https://fetch.spec.whatwg.org/#body-mixin

In the section "Request Class" the new Request(input, init) constructor is a minefield of potential TypeErrors:

The new Request(input, init) constructor steps are:
...
6. If input is a string, then:
...
2. If parsedURL is a failure, then throw a TypeError.
3. IF parsedURL includes credentials, then throw a TypeError.
...
11. If init["window"] exists and is non-null, then throw a TypeError.
...
15. If init["referrer" exists, then:
...
1. Let referrer be init["referrer"].
2. If referrer is the empty string, then set request’s referrer to "no-referrer".
3. Otherwise:
1. Let parsedReferrer be the result of parsing referrer with baseURL.
2. If parsedReferrer is failure, then throw a TypeError.
...
18. If mode is "navigate", then throw a TypeError.
...
23. If request's cache mode is "only-if-cached" and request's mode is not "same-origin" then throw a TypeError.
...
27. If init["method"] exists, then:
...
2. If method is not a method or method is a forbidden method, then throw a TypeError.
...
32. If this’s request’s mode is "no-cors", then:
1. If this’s request’s method is not a CORS-safelisted method, then throw a TypeError.
...
35. If either init["body"] exists and is non-null or inputBody is non-null, and request’s method is GET or HEAD, then throw a TypeError.
...
38. If body is non-null and body's source is null, then:
1. If this’s request’s mode is neither "same-origin" nor "cors", then throw a TypeError.
...
39. If inputBody is body and input is disturbed or locked, then throw a TypeError.

The clone() method steps are:

  1. If this is disturbed or locked, then throw a TypeError.

In the Response class:

The new Response(body, init) constructor steps are:
...
2. If init["statusText"] does not match the reason-phrase token production, then throw a TypeError.
...
8. If body is non-null, then:
1. If init["status"] is a null body status, then throw a TypeError.
...

The static redirect(url, status) method steps are:
...
2. If parsedURL is failure, then throw a TypeError.

The clone() method steps are:

  1. If this is disturbed or locked, then throw a TypeError.

In section "The Fetch method"

The fetch(input, init) method steps are:
...
9. Run the following in parallel:
To process response for response, run these substeps:
...
3. If response is a network error, then reject p with a TypeError and terminate these substeps.

In addition to these potential problems, there are some browser-specific behaviors which can throw a TypeError. For instance, if you set keepalive to true and have a payload > 64 KB you'll get a TypeError on Chrome, but the same request can work in Firefox. These behaviors aren't documented in the spec, but you can find information about them by Googling for limitations for each option you're setting in fetch.

In my case I got "TypeError" when using online JS tools like jsfiddle or stackblitz and the problem was that my url was http instead of https.

Behind the scenes the XHR client sends an HTTPOPTIONS request, called pre-flight, to look for certain security permission headers, called CORS Allow headers. If the required headers are not found (as in you might not have the necessary permissions), TypeError is the result since it has not actually tried to send your POST/GET request. You can observe this behavior in the browser console: it looks like the browser makes two requests to the same location, first having the HTTP Method: OPTIONS.

I was getting this issue since I have not added CORS in my flask app. I need to add it, then it worked, here are the lines:

...
from flask_cors import CORS


def create_app(test_config=None ):


app = Flask(__name__)


app.config.from_object('config')  # Import things from config


CORS(app)


# CORS Headers
@app.after_request
def after_request(response):
response.headers.add('Access-Control-Allow-Headers', 'Content-Type,Authorization,true')
response.headers.add('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE,OPTIONS')
return response


...


I had this same error when using Firebase Cloud Functions and was able to fix it using the CORS npm package like this:

const functions = require("firebase-functions");
const cors = require('cors')({origin: true});


exports.exampleCORSFunction = functions.https.onRequest((req, res) => {
cors(req, res, () => {
//do your CORS stuff
return res.send({response: "success"});
});
});

Wrap your cloud function in the CORS module and it will return header values the allow for cross origin.

This question comes up first when googling the same error, so sharing the solution here for others:

If you use Sentry, you need to add the 'sentry-trace' value to your servers Access-Control-Allow-Headers list.

Issue here https://github.com/getsentry/sentry-javascript/issues/3185

In my case, this error was caused by the missing always parameter to the add_header directive of nginx.

For example, when our backend was sending an error response, such as in PHP header('HTTP', ERROR_CODE), was resulting in CORS headers missing from response.

As the docs states about add_header directive

Adds the specified field to a response header provided that the response code equals 200, 201 (1.3.10), 204, 206, 301, 302, 303, 304, 307 (1.1.16, 1.0.13), or 308 (1.13.0).

and about always parameter

If the always parameter is specified (1.7.5), the header field will be added regardless of the response code.

Adding the always parameter to any required headers fixed the issue for me, like so:

add_header HEADER_NAME "HEADER_VALUE" always;

after struggling a few hours on that error, I would like to share my solution

<a
:href="some_props_with_default_value"
@click="externalCalculationViaFetch()"
>
Calculate
</a>

There was a problem with some_props_with_default_value that generating a page refresh.

The page refresh was canceling the fetch request before getting a response and raising this error.

Went back to normal when fixing the page refresh :

<a
@click="externalCalculationViaFetch()"
>
Calculate
</a>

Hope it helps someone.

In my case I was trying to make fetch requests to my Django API via localhost and I was able to make it work by changing my URL from:

var url = "http://127.0.0.1:8000/";

to:

var url = "http://localhost:8000/";