I make an XHR Post request in Chrome and it immediately returns with an response with a type of error with no detail info. In Chrome the response status shows up as "canceled". However the request actually reaches the server and is processed by the server (verified with a breakpoint). But the XHR error response and Chrome response status of "canceled" occurs before the request reaches the server. I'm testing using a local webserver and app server with a single origin of "local.mydomain.com". So there is no cross-domain implications. What could be causing this behavior?
Related
I am using XmlhttpRequest to send a POST requests on localhost and chrome developer tools console and network to verify the requests.
I have two methods:
Method1 send the post requests.
Requesthandler handles the requests response.
When the request is successful (200) it does not throw an error and the request handler outputs a message on console. But when the request is unsuccessful. My console throws an error despite the request handler.
For example, If I purposely set the wrong url adress. I expect a 404 status Not Found exception and the request handler to output a message on console. Despite it happening, it still goes ahead and throws on the error on Send() Method.
Why xmlhttprequest.send() throws errors despite handling responses on the onreadystatechange event?
Method1(Sends Requests)
RequestHandler(Handles responses)
Console Message:
Thrown Error:
Using CefSharp version 71.
While making fetch() call from JavaScript, it should ideally make the pre-flight OPTIONS call before making the GET/POST call.
But it doesn't actually make it.
But if I try it in the Chrome browser, it does.
Tried this on Chrome browser, and it does make the pre-flight OPTIONS call.
The result of this is, since OPTIONS call is not made, CORB is stopping the response.
The error is:
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://some-api.com/blah with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.
It looks like WebSecurity is set to disabled in your BrowserSettings.
browserPlay.BrowserSettings = new BrowserSettings()
{
WebSecurity = CefState.Disabled
};
Steps to Reproduce:
Add the above code in the application
Make a cross origin GET Request, notice that the request is made without "Origin:" header and Response does not have CORS headers.
In console, you will see the following CORB error: Cross-Origin Read Blocking (CORB) blocked cross-origin response
I tested the above on CEF version 73.1.13
We have been encountering inconsistent client errors with a single-page JavaScript application making fetch requests. Of note, they are all same-origin requests.
let request = new Request(url, options);
...
window.fetch(request)
.then(response => response.json())
.then(data => ...)
.catch(error => ...)
Around 5% of the promises are rejecting with the following error despite the server and the browser receiving a 200 OK response:
TypeError: Failed to fetch
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.
EDIT:
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.
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)
The issue could be with the response you are receiving from back-end. If it was working fine on the server then the problem could be with the response headers. Check the Access-Control-Allow-Origin (ACAO) in the response headers. Usually react's fetch API will throw fail to fetch even after receiving response when the response headers' ACAO and the origin of request won't match.
Ref: Getting "TypeError: failed to fetch" when the request hasn't actually failed
Medium has an RSS feed available at https://medium.com/feed/[#username]. I'm trying to fetch all my blog posts using an XMLHTTPRequest. When I test on local, I run into CORs errors. When I turn on CORs Chrome extension, I get a 401 error. Any ideas? Has anyone succeeded in calling Medium RSS?
To get https://medium.com/feed/[#username] content using XHR, you can make the XHR request through a proxy of some kind. For example, trying giving your current XHR code this URL:
https://cors-anywhere.herokuapp.com/https://medium.com/feed/#sideshowbarker
That’ll cause the request to go to https://cors-anywhere.herokuapp.com, a open/public CORS proxy which then sends the request on to https://medium.com/feed/#sideshowbarker.
And when that proxy gets the response, it takes it and adds the Access-Control-Allow-Origin response header to it and then passes that back to your requesting frontend code as the response.
That response with the Access-Control-Allow-Origin response header is what the browser sees, so the error message the browser is showing you now goes away, and the browser allows your frontend JavaScript code to access the response.
Or use the code from https://github.com/Rob--W/cors-anywhere/ or such to set up your own proxy.
The reason you need a proxy is, responses from https://medium.com/feed/[#username] don’t include the Access-Control-Allow-Origin response header, so your browser will refuse to let your frontend JavaScript code access those responses cross-origin.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS has more details.
This is a bug.
Bug has opened. (Dan Abramov approved)
I made a cross site request and the server is not in my control,.
So how can I get the response value?
I can see the response json value in the console of Firefox as shown below :