I am doing a site using react. The site is using API /api/auth/login for logging. But for now the database has problem, so the api returns error 500.
But I got weird issue in Chrome. In Chrome, it shows the CORS error:
This is response of OPTIONS:
As we saw in response of OPTIONS: the Access-Control-Allow-Origin is set to *
In Firefox, I can see the response with error 500.
I don't know why Chrome has different behavior.
Please share your thinking.
Thank you.
Related
I want to crawl the content of the following page:
http://www.aae3.com/bt/cl/x7btc.php?download=down
When I use Chrome to open this page, I can see an empty file named torrent been downloaded.
If I use devtools in Chrome I can see the request returns 200.
Chrome Devtools Screenshot
And then, I tried to use postman to get this page, no matter how I fill in headers, postman always fail to get any response.
Postman Get Request Test
Why is there such difference? What should I do to get the same behavior with Chrome browser?
Compare the Request Headers, maybe there is a difference another agent Setting which is handled different.
I'm writing a API call with Fetch() to download a file from another Domain. The process is: A fetch() method is calling in DomainA to an API in DomainB, then the API returns the response with location in repsonse's header, the location is an url of DomainC.
In Chrome and IE, it works well. Based on the Network Inspection, we can see 3 http requests here.
A. An OPTIONS request to the API, the response Status code 200;
B. An GET request to the API, and the response status code is 302 and
in the response Header, location property contains the target file
location (http url).
C. A request to the target file location to download the file.
But in Firefox and Edge, we can only see the request A) and B). Both of their responses are expected. While there is no 3rd request to download the data. Within debugging, we can see an error is thrown in the fetch().catch(error){}, the error is TypeError:
In Firefox:
TypeError: NetworkError when attempting to fetch resource. In Edge:
TypeError: Failed to fetch
I just did some investigation on this issue.
According to Http-redirect fetch, it should work well since CORS is configured correctly. I guess Firefox or Edge may implement their native fetch() method which leads an failure here.
Does anyone know what's going on here? Thanks.
I have been looking for a way to understand the root cause of the "The server encountered an error processing the request. See server logs for more details." problem in my particular case but none of the existing online solutions addresses the problem I am about to describe.
I need to send POST requests with JSON payload {"userName", "Adnan"} to an Azure-based web service which eventually retrieves some database GPS records in a HTTP response. My initial attempt to test this POST request worked fine via Fiddler (See image below) and Android OKHttp libraries.
However, when I tested the same request over my ultimate 3G platform, it gave the above-mentioned error. I managed to replicate the same error with the Chrome Postman plugin (See image below). It must be noted that even if I am sending the data as a JSON payload, the same error appears on the Postman plugin. Almost all the solutions to this problem online suggest on tweaking the webservice itself which should not be the case as it works fine with Fiddler and Android. So - my question is why the POST request shown above is not working with the Postman plugin. I believe if the problem is resolved on Postman, it would be resolved on my 3G embedded board as well. Thank you.
I have deployed my asp.net MVC app to production, and it works as expected. However, when using F12 in IE to see the Network requests that are being made to the server, I see the requests being sent with this format:
http://172.16.10.2/VMSWebTest/(F(pZPg-rE4Nghw1pU6TbKBwuNIeLCVHnerv1BO7BG3hZlmLxqretATeKFdrZU2b9Qr_rg2-wieUwZOJ9PkcwWdRzRSP_oUEI5mdmd4vzbrqbM1))/Tiers
instead of this format:
http://172.16.10.2/VMSWebTest/Tiers
Where is that (F(pZPg-rE4Nghw1pU6TbKBwuNIeLCVHnerv1BO7BG3hZlmLxqretATeKFdrZU2b9Qr_rg2-wieUwZOJ9PkcwWdRzRSP_oUEI5mdmd4vzbrqbM1)) part of the URL coming from? Why? What is it's purpose?
I've noticed this only seems to be with IE, as the request url are as expected when using Chrome.
It might be that you are the victim of a bug where ASP.NET can not recognize IE10, please see the suggestions in this answer:
IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
Specifically, there is a hotfix available: http://support.microsoft.com/kb/2600088
We have a simple HTML login form on our embedded device's web server. The web server is custom coded because of severe memory limitations. Regardless of these limitations, we like Chrome and would like to support it.
All browsers post an HTTP Request to our login form containing the expected "username=myname&password=mypass" string, but not Chrome. Instead we receive from Chrome a "Content-encoding gzip deflate" request. BTW, by "all browsers", I mean this was tested to work fine on Internet Explorer versions 9 beta, 8, 7, 6 ; Firefox versions 4 beta, 3, 2 ; Opera 10, 9 ; Safari 5, 4, 3 ; and SeaMonkey 2.
Referring to section "14.2 Accept Charset" of the w3.org's http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html we tried sending back a HTTP 406 code to indicate that this server does not support that encoding in the hope that Chrome would try again and post the expected strings the standard way. The 406 code returned by the web server is clearly displayed in Chrome's "Inspect Element" window, but it seems to be treated by Chrome as an error code, and no further requests are sent to the web server. "Login failed." We also tried HTTP return codes 405 and 200, same result.
Is there a way to get around this behavior either with client-side JavaScript that will prevent Chrome from sending the "Content-encoding gzip deflate" request, or with a server-side response that will explain nicely to Chrome we don't do gzip, just send it to us the regular way?
We tried posting to the Google Chrome Troubleshooting forum with no response.
Any help would be greatly appreciated!
Best regards,
Bert
You're looking in the wrong section for the error code: Section 14.11 of RFC 2616 specifies that you send a 415 (Unsupported Media Type) if you can't deal with the Content-Encoding.
It sounds like when using chrome to do a post to a server the first time, chrome defaults to using a gzip encoding. Pretty strange.
Easy way out is to just place your username/pass as GET parameters, and when sending the response, as long as you don't send gzip content encoding, chrome should start using none-gzipped posts from that point on. Hope that works?
I tested this out a bit with a simple Python script that printed to stdout. I thought I was getting the same problem, but then I realized that I was just forgetting to flush stdout. It seems that Chrome always sends the request up to the end of the headers before sending the request content, and you have to use a second recv call to get the POST data. In contrast, the entire Firefox request is returned in a single recv call.