Making a get request to an HTTP REST API from an Ionic and Angular app. When making the request on a home network the API receives and responds correctly to every request.
However, when I make the same request on a 4g data connection only the first request is successful. In all following requests, the server never receives said request, but the $http.get acts as though it receives a response and reports a status code of 200. In these cases the "response" never changes from the response the initial request resulted in.
Clearing the app data restarts this cycle: the first request after the clear succeeds, and that response is repeated.
This is the function which makes the GET request. The contents of res are shown in the screenshot below.
this.getSongInfo = function() {
return $http.get('http://REDACTED:8080/getName').then(function(res) {
console.log(res);
return res.data;
}, function(err) {
console.log(err);
return false;
});
}
UPDATE
Lex's answer helped. I had not realised I couldn't inject $httpProvider into a service. Once I added it as to my app.config everything seemed to work correctly. Still not sure why it was only caching when on a data connection though, I couldn't find anything in the angular documentation to say that caching is enabled for data connections.
It sounds like the response is being cached somewhere. This is useful when you expect the same request to return the same response every time, but your case, that's obviously not the desired behavior. Based on what you've provided there is no way to know what external tool/setting is causing the response to be cached.
Related
We run our staging environment on a shared host. Occasionally we run into troubles with unknown errors. Cloudflare displays it as error 520 when the page loads.
It's not a resource problem, and we don't have server access. It really does not happen often, so I want to run a Cloudflare Worker that refreshes the page if there is a 520 error.
Does anyone know how to write this, please?
Something like below should do it. Note that this doesn't "refresh" the page. Instead, the error page never reaches the user's browser at all, because on an error, the whole request is retried and the retry response goes to the browser instead.
Of course, it would be better to figure out why the error is happening. Cloudflare's error 520 means that your origin server is returning invalid responses to Cloudflare. Here is a page discussing what to do about it.
That said, while the problem is being investigated, a Worker can offer a convenient way to "sweep the problem under the rug" so that your visitors can access your site without problems.
export default {
async fetch(request, env, ctx) {
if (request.body) {
// This request has a body, i.e. it's submitting some information to
// the server, not just requesting a web page. If we wanted to be able
// to retry such requests, we'd have to buffer the body so that we
// can send it twice. That is expensive, so instead we'll just hope
// that these requests (which are relatively uncommon) don't fail.
// So we just pass the request to the server and return the response
// nomally.
return fetch(request);
}
// Try the request the first time.
let response = await fetch(request);
if (response.status == 520) {
// The server returned status 520. Let's retry the request. But
// we'll only retry once, since we don't want to get stuck in an
// infinite retry loop.
// Let's discard the previous response body. This is not strictly
// required but it helps let the Workers Runtime know that it doesn't
// need to hold open the HTTP connection for the failed request.
await response.arrayBuffer();
// OK, now we retry the request, and replace the response with the
// new version.
response = await fetch(request);
}
return response;
}
}
I am looking at the digest-fetch.js over the fetch API, and I am finding some problems. The issue is that in my scenario a POST call is made, responded first with 401 with the challenge and then retried with the authentication header, then succeeds. So far, so good.
But our server responds deliberately with 303, giving a different URI (on same server) to pick up the final result.
The fetch API does not allow me to manually handle the redirect (which I totally don't get why this would be considered "insecure" and hence hidden) but when the core fetch API will retry that, it gets a 401 again from our server. At that point it will fail.
I think this is because the fetch API re-uses the headers, namely the Authorization header, as a constant string. That same header is used for the follow-up GET request on the 303 redirection. The server barks that the nc has not been increased.
As [https://en.wikipedia.org/wiki/Digest_access_authentication] says:
[...] the client may make another request, reusing the server nonce value (the server only issues a new nonce for each "401" response) but providing a new client nonce (cnonce). For subsequent requests, the hexadecimal request counter (nc) must be greater than the last value it used [...]
I consider this a bug in digest-fetch but worse in the Fetch API (of Chrome and Firefox anyway).
I have tried not to provide a String header, but an object with a toString method, hoping that this would be called every time a request is made. So, instead of:
options.headers.Authorization = digest;
I did:
options.headers.Authorization = {
toString: function() {
alert(new Error("Gotcha! " + digest));
return digest;
}
}
Yet sadly, that gets called only once. I think out of the core fetch API function, where I am afraid a string is stored, and the toString() method will not again be called.
Any workaround this problem?
I have a question.
I send a Get request by Ajax every second and expect to get some response from the server.
In the case and my application crashes and I continue to send Get request every second, I don't get any response until receiving the server's timeout error (an error code 502.) .
If somebody knows how I can handle this moment between sending the get requests every second and until receiving error code 502.
Thanks
If the server is down, whatever you are using for the ajax call should have errored out... in which case you should handle it with a call back or a catch block. There, you should handle what you will do on the frontend based on the response.
As far as not sending out more requests, there really is no way to know for sure. For all your code knows, the server is particularly slow at that moment.
I need to create REST API endpoint, and I am not sure which HTTP code to return as status.
Requirements are next:
- My API should accept URL as a parameter
- Make an API call to third-party service (use URL), and get a response
- Return response (content that fetched from third-party service)
In some cases, everything works fine. A call is made to external service, it returns content and status code 200.
But, sometimes there is no content and it returns 404. (Important, it is possible that content will be available in the future.)
From the perspective of my system, it is the regular situation.
Which HTTP code should I return?
202 - Accepted,
204 - No content,
206 - Partial content
or something else?
404 Not Found
The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
In REST-API request and response should only work with current "call". If the content is currently not available it should return 404 status. And It(404) is the exact status that should be returned.
However, if you want to bend the rules, 204 status code seems more appropriate. I'm not recommending you to do this.
204 No Content
The server successfully processed the request and is not returning any content Link.
Instead of creating the actual resources, create a temporary one. Instead of returning a 201 (Created) HTTP response, you can issue a 202 (Accepted) response code. This informs the client that the request has been accepted and understood by the server, but the resource is not (yet) created.
From: http://restcookbook.com/Resources/asynchroneous-operations/
You should return whatever the HTTP status code return by third party service unless your system is wrapping it up and processing it and changing the status.
I'm using appAPI.request to make ajax calls to an external web API. This works very well, but the API sends HTTP status codes other than 200 when something goes wrong. It also sends the error message/code when this happens. As the onFailure callback does only returns the http error code, but not the response message, i'm unable to read the error message sent by the server. Is there any way to retrieve the response message when onFailure gets called?
As of now, the HTTP response text is not currently available in the onFailure callback. However, as we are constantly working on improvements, we will add this to our API in future releases.
Disclaimer: I am a Crossrider employee