Ошибка failed to fetch что это

Network error typeerror failed to fetch что это

Reading time В· 6 min

TypeError: Failed to fetch and CORS in JavaScript #

The «TypeError: Failed to fetch» occurs for multiple reasons:

1. An incorrect or incomplete URL has been passed to the fetch() method.
2. The server you are making a request to doesn’t send back the correct CORS headers.
3. A wrong protocol is specified in the URL.
4. A wrong method or headers have been passed to the fetch() method.

Here’s an example of how the error occurs.

The URL we passed to the fetch() method is incorrect, so we got back two errors:

• CORS — «No ‘Access-Control-Allow-Origin’ header is present on the requested resource.»
• «TypeError: Failed to fetch»

Make sure the specified URL is correct and complete #

Make sure that the URL you’re passing to the fetch() method is correct and complete. You have to:

• include the protocol, e.g. https:// or http:// if you’re testing on localhost without an SSL certificate
• the path has to be correct e.g. /articles
• the HTTP method (e.g. GET or POST ) has to be correct for the specific path (e.g. /articles )
• if you misspell any of the configurations, e.g. a property in the headers object or the HTTP method, the error occurs.

Make sure to pass the correct configuration to fetch() #

To solve the «TypeError: Failed to fetch», make sure to pass the correct configuration to the fetch method, including the URL, HTTP method and headers, and verify that the server you’re making a request to is setting the correct CORS headers with the response.

If the configuration you pass to the fetch method is correct, check if your server is sending the correct CORS headers in the response.

Check if your server sends back the correct CORS headers #

The server should be setting the following CORS headers along with the response:

You might have to tweak the values depending on your use case, but open the Network tab in your browser, click on the request and check if your server is setting these CORS-related headers.

Источник

Почему возникает TypeError: Failed to fetch при запросе к серверу из VK Mini App только из приложения на Android?

На сервере запущен Express-сервер, у него разрешены кроссдоменные запросы, настроен сертификат, и у браузеров нет проблем с тем, чтобы получить оттуда статическую страницу, или сделать на него запрос к API, в том числе, если приложение запущено в браузере на сайте ВК (статика подгружается из ВК, поэтому запросы кроссдоменные).

Более того, если открыть приложение в официальном клиенте на iOS, то запросы к серверу также проходят, и всё работает.

И только если приложение открыто в официальном клиенте на Android, запрос не просто не успешно завершается, а он даже, возможно, не начинается, выкидывая исключение TypeError: Failed to fetch.

Я добавил в приложение консоль Eruda, чтобы посмотреть на код запроса или заголовки, но даже их нет, в консоли (во вкладке работы с сетью) просто написано pending. и статус unknown.

При этом, точно такой же код при обращении к сторонним доступным извне API, типа курсов валют (используя GET, но GET также не работает в случае моего сервера), работает прямо из приложения:

Проблема возникла точно не из-за кроссдоменности, так как изначально я хостил и API, и статику, но статику получилось выгрузить в ВК через их технологию Deploy, а до этого приложение не получало даже статики и вечно загружалось, в то время как браузеры на всех моих устройствах не видели проблем с тем, чтобы получить от моего сервера как статику, так и ответ на POST-запрос.

Так как код выполняется всеми браузерами, включая даже Edge, нельзя назвать клиентскую часть сильно проблемной, хоть и что-то в ней, возможно, не так. Более того, ещё до запуска клиентской части, когда я пытался хостить статику, приложение само делало к статике GETы, которые не «выходили» (скорее всего) из приложения.

Помимо этого, я пробовал запускать Restify на сервере, чтобы хоть какой-нибудь маленький бесполезный запрос всё же прошёл, но и в этом случае браузеры получали ответ, а код внутри приложения ВК — нет.

В случае же, если использовать Ngrok или VK-Tunnel, всё работает, но это совсем не то, что нужно, учитывая, что адрес не будет постоянным.

Единственное, что примечательно в моей серверной части — сервер слушает только 443 порт, без 80, а также то, что домену, как и сертификату всего около недели, и, возможно, к ним из-за этого мало доверия. Но сертификат, хоть и новый, настоящий (не самодельный), куплен в RU-CENTER, назывался там «GlobalSign DomainSSL», один из тех, что доступен для физлиц, и браузеры на всех устройствах не жалуются, пишут, что всё безопасно.

Не нашёл в интернете подобных ситуаций, так как на мой взгляд сама ситуация не вполне адекватна, учитывая то, что WebView в приложении ВК должно вести себя с сетью также, как и ведущие браузеры на том же устройстве.

Надеюсь, можно как-то изменить код на серверной или на клиентской стороне, чтобы запросы проходили при открытии приложения внутри приложения ВК на Android.

Источник

How to fix ‘TypeError: Failed to fetch’?

I’m getting a TypeError: Failed to fetch error when I attempt to send a post request using fetch on the front-end and an express route on the back-end.

I’m able to successfully create the new user in the db, but when attempting to obtain that new user data through the fetch promise, that’s when the error is being thrown.

app.js

users.js

server.js

I need to get that user object back in order to access its data.

Edit: So, I’ve figured out that the issue has to do with how the request is submitted on the front-end. If I create the following function and then call it when app.js is loaded, then everything works:

But, if I try to call this function either through onsubmit in the form or onclick on the button in the html, or if I use an event listener (see below, which is in app.js ), then I get the TypeError: Failed to fetch error:

This is even more baffling to me. I’m required to use Vanilla JS and I need to create the user through a form submission, but not sure what I need to adjust here.

Solution Foiled by the event.preventDefault() again. This was all I needed.

3 Answers 3

The issue was that the page was reloading, which kept me from getting the data back in time. The solution was to simply add event.preventDefault() inside the listener.

app.js

The question is about «TypeError failed to fetch». The wording of the message sends one in the direction of network/server/CORS type issues as explored in other answers, but there is one cause I have discovered that is completely different.

I had this problem and took it at face value for some time, especially puzzled because it was provoked by my page POSTing in Chrome but not in Firefox.

It was only after I discovered chrome://net-internals/#events and saw that my request suffered from ‘delegate_blocked_by = «Opening Files»‘ that I finally had a clue.

My request was POSTing a file uploaded from the user’s computer via a file input element. This file happened to be a file open in Excel. Although it POSTed fine from Firefox, it was only when closed that it could be posted in Chrome.

Users of your web application need to be advised about this potential issue, and web developers should also be aware that «TypeError failed to fetch» can sometimes mean «TypeError didn’t get as far as trying to fetch»

Источник

Fetch throws «TypeError: Failed to fetch» for successful, same-origin request

We have been encountering inconsistent client errors with a single-page JavaScript application making fetch requests. Of note, they are all same-origin requests.

Around 5% of the promises are rejecting with the following error despite the server and the browser receiving a 200 OK response:

I’m stumped. All of my searches lead to discussions about CORS errors. That doesn’t seem to apply given these are all same-origin requests. What is causing the fetch to throw the TypeError ?

I can confirm using the Network tab in Chrome DevTools that the fetch request completes with a 200 OK response and valid JSON. I can also confirm that the URLs are same-origin. I can also confirm that there are no CORS pre-flight requests. I have reproduced this issue on Chrome 66 and Safari 11.1. However, we’ve received a stream of error reports from a mix of Chrome and Safari versions, both desktop and mobile.

This does not appear to be a duplicate of the linked question as we are not sending CORS requests, not setting mode: «no-cors» , and not setting the Access-Control-Allow-Origin header.

Additionally, I re-ran tests with the mode: ‘same-origin’ option set explicitly. The requests are (still) successful; however, we (still) receive the intermittent TypeError .

2 Answers 2

I know that this is an old issue, but after searching the entire evening I want to share my findings so you can spend your time better.

My web app also worked well for most users but from time to time visitors received the error mentioned in the question. I’m not using any complicated infrastructure (reverse proxy etc.) setup nor do I communicate with services on a different domain/protocol/port. I’m just sending a POST request to a PHP-File on the same server where the React app is served from.

The short answer: My problem was that I’ve sent the request to the backend by using an absolute URL, like https://my-fancy-domain.com/funky_service.php . After changing this to a relative path like /funky-service.php the issue was gone.

My explanation: Most users come to the site without www in the URL, but some users actually do type this part in their address bars ( www.my-fancy. ). It turned out that the www is part of the origin, so when these users submit the form and send post requests to https://my-fancy. it’s technically another origin. This is why the browser expects CORS headers and sometimes even sends an OPTIONS preflight request. When you use a relative path in your JavaScript-Code the post request will also include the www-part (uses the origin from the address bar) -> same-origin -> no CORS hassle. As it only affects visitors that come with the www to your site it also explains the fact that it worked for most users even with the absolute URL.

Also important to know: The request fails in the browser/ JavaScript-Code but is actually sent to the backend (very ugly!).

Let me know if you need more information. Actually, it is very simple but hard to explain (and to find)

Источник

Finally We Fixed «Failed to Fetch» Error

Our Apollo Server is running on AWS Lambda using Serverless Framework, and then it’s accessed thru AWS API Gateway using Cognito User Pool as an authorizer.

More information about Amazon Cognito User Pools can be found in this article.

Our frontend (CMS) is running on top of Create React App with Apollo Client.

On the localhost, we use serverless offline, so there is not API Gateway, Cognito User Pool, and Lambda in between the Apollo Client and Apollo Server.

We received a lot of complaints from the CMS users that they got the “Failed to Fetch” error a few times almost every day when they were working on the website. When that happened, the CMS cannot communicate to the API server. With console log enable, we saw the information like below:

[Network error]: TypeError: Failed to fetch

Access to fetch at ‘https://API-URI/graphql’ from origin ‘https://CMS-URL’ has been blocked by CORS policy: «No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

Failed to load resource: https://API-URL/graphql:1 net:ERR_FAILED

The hard part to solve this issue is that:

1. There wasn’t useful information that could be found in the AWS Cloudwatch
2. We could not reproduce it on the local, or on production (with brief test)

After spending a lot of time checking the network connection (the CMS can only access via VPN), API Gateway, Lamba, RDS proxy, MySQL database, etc., everything that is different between Localhost and Production, we still could not find the clues.

We were pretty sure that the CORS is enabled on Apollo Server. Somehow the server’s response does not send the No «Access-Control-Allow-Origin’ header, and the client does not set the request’s mode to ‘no-cors’, so the browser throws this error.

More informatio about CORS error could be found in this article

So, how about eliminating the CORS log first? We need to see the real error log.

All debugging starts from the log — Adam C.

We took a second look at the API Gateway and found that we should manually add the “Access-Control-Allow-Origin” header to 4xx and 5xx response, otherwise, this header will be missing from the response, and then the real 4xx and 5xx error will be hidden, because the browser will complain CORS errors as shown above.

After adding this header with the value “*”, we got the new error report from our CMS users. As expected, we saw the real error message:

Failed to load resource: the server responded with a status of 401 ()

[Network error]: ServerError: Response not successful: Reveived status code 401

After finding the root of failure, the fixing became much more targetable. We quickly figured out that it’s related to the Cognito user pool, which we use as an authorizer. The AccessToken and IDToken are set with a short expiration time of one hour, so if the user is on the website for more than one hour, he/she will use pass an expired token for API call, therefore, the 401 unauthorized error will be received. Also, after refreshing the page, everything is back to normal, that’s because the lifetime of refreshToken is one day, and Amplify will auto-refresh the AccessToken and IDToken as long as the refreshToken is not expired.

So the solution is clear that we just need to refresh the AccessToken/IDToken when they are expired, but we need to do this in the background without refreshing the page, otherwise, the user’s unsaved work will get lost.

We use Amplify React UI Component to handle user login. When the login is successful or the user is already logged in, the ID token is passed to Apollo authLink as below:

The logic above is implemented in the App.js, which is the parent component of all, and it’s only run once at the componentDidMount lifecycle, so without refreshing the page, the token is never changed. But as we learned above, when the token is expired, the 401 unauthorized error is received. The Apollo Client allows us to check for a certain failure condition or error code, and retry the request if rectifying the error is possible. Below is what we came up using the ErrorLink: (If you are not familiar with Apollo Link, check it out here)

Note the in our case, the 401 unauthorized is captured in networkError, and the error string contains “ Received status code 401” which we used to filter, and Auth.currentAuthenticatedUse, the function provided by ‘Amplify’ is asynchronous, so we have to use fromPromise, the function provided by ‘apollo-link’ to token from a Promise object, and then replace the old header in operation context, finally forward the operation to retry.

After this, we had the annoying ‘failed to fetch’ error fixed. 🙂

Источник

POST https://localhost:5000/add-user/ net::ERR_CONNECTION_CLOSED

Uncaught (in promise) TypeError: Failed to fetch

Делаю запрос через свой хук, подскажите пожалуйста в чем может быть проблема?
CLIENT

const useDb = useDatabase();
<button onClick={() => useDb.addUser(userInfo.email, userInfo.name, userInfo.password)}>Submit</button>

HOOK

export default function useDatabase() {

    function addUser(email, name, password) {
        let newUser = {
            email: email,
            name: name,
            password: password
        }
        fetch(`https://localhost:5000/add-user/`, {
            method: 'POST',
            headers: {'Content-type': 'application/json'},
            body: JSON.stringify(newUser)
        }).then(data => console.log(data));
    }

    return {addUser}
}

SERVER

const dotenv = require('dotenv');
const dbService = require('./dbService');
const cors = require('cors');
dotenv.config();

const express = require('express');

app = express();
app.use(cors());
app.use(express.json());
const port = process.env.SERVER_PORT;

app.listen(port, () => {console.log('server started on port ' + port)})

app.post('/add-user', function(req, res) {
    console.log(req.body)
});

Bitwarden может иногда выдавать раздражающую ошибку « Failed to Fetch », когда вы пытаетесь войти в настольное приложение. Та же ошибка может иногда влиять и на расширение вашего браузера. Если ошибка «Failed to Fetch» ​​не позволяет вам использовать диспетчер паролей на вашем устройстве, используйте решения по устранению неполадок, перечисленные ниже.

Обновите приложение

Запуск устаревших версий приложений в последних выпусках ОС может вызвать всевозможные проблемы, включая проблемы со входом. Если вы используете локальный экземпляр на Mac, запустите Терминал и выполните следующие две команды:

• ./bitwarden.sh updateself
• ./bitwarden.sh update.

Если вы работаете в Windows, запустите командную строку с правами администратора и выполните следующие команды:

• . bitwarden.ps1-updateself
• . bitwarden.ps1-update.

Отключите брандмауэр

Временно отключите брандмауэр и проверьте, можете ли вы войти в свою учетную запись Bitwarden. Вы можете повторно включить защиту брандмауэра после входа в систему. Если этот метод сработал, убедитесь, что добавить Bitwarden в белый список в настройках брандмауэра .

Переустановите Bitwarden

Если проблема не исчезнет, ​​удалите Bitwarden и перезагрузите компьютер. Затем снова загрузите приложение, переустановите его и проверьте, работает ли оно должным образом. Загрузите приложение с официального сайта, а не из App Store или Microsoft Store.

Исправить ошибку Bitwarden «Не удалось получить» в браузере

Очистить кеш

Кэш вашего браузера и файлы cookie могут мешать Bitwarden. Это могло вызвать длинный список сбоев, включая проблемы со входом в систему и ошибку «Failed to fetch». Перейдите в раздел История вашего браузера, выберите параметр Очистить данные просмотров и очистите кеш. Если вы используете Chrome, воспользуйтесь этим пошаговым руководством , чтобы очистить кеш.

Отключите ваши расширения

Другие расширения, установленные в вашем браузере, могут нарушать сценарий входа Bitwarden. Отключите все ваши расширения, перезапустите браузер и проверьте результаты. Конечно, убедитесь, что Bitwarden-единственный менеджер паролей, работающий на вашем устройстве.

Переустановите Bitwarden

Если ничего не помогло, удалите Bitwarden. Если проблема входа в систему вызвана ошибками с недействительными сертификатами, установка новой копии Bitwarden должна исправить это.

Заключение

Подводя итог, если ошибка «Failed to Fetch» ​​не позволяет вам войти в Bitwarden, временно отключите брандмауэр и проверьте, исчезла ли проблема. Если проблема не исчезнет, ​​переустановите приложение. Если эта ошибка затрагивает расширение Bitwarden, очистите кеш, отключите другие расширения и переустановите расширение Bitwarden.

Вы по-прежнему сталкиваетесь с ошибкой «Не удалось получить»? Дайте нам знать в комментариях ниже.

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.