login request is sending twice .what is the problem ?
If you check the request method, the first request has method OPTIONS, this is a "Preflight" request, which you can read about here:
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
It shouldn't actually execute your code assuming your routes are bound to a specific HTTP method, e.g., GET/POST
Related
I have API call and it is taking 0.5 seconds in postman whereas the same API call taking 10 seconds with axios. How should I increase this speed?
Actually, in the browser, you make 2 requests, unlike Postman. One is OPTIONS for check CORS and one is GET, POST, etc. Your API server returns a header when OPTIONS request which is Access-Control-Max-Age. Access-Control-Max-Age value stands for how long wait for the next OPTIONS request. May your API was not set an Access-Control-Max-Age header or set for too short therefore your browser always makes 2 requests. Needs to be more investigation here to be sure.
There is no other way for improve speed with Axios because postman is s/w and axios is package lib with different functionality and using your application to run it while postman run api directly thats why its faster than axios.
The Postman isn't a browser so it will not worry about CORS and can send the POST without sending the OPTIONS, so only incurs the cost of the POST.
and your sever may take time to process the OPTIONS request and then the POST request so whether you are using axios or fetch even XHRHttpRequest it will take more time than postman
I have this request that is querying my service which is inside of tryMax.
The access token to authenticate a request expires every five minutes and is generated at the beginning of the simulation run as ${token}
Is there a way within the tryMax to send another token generation request that will update the expired ${token} (Authorization header value) if the response code is 401 or the response body contains information about the request not being authenticated. Then retry the request before tryMax moves to the next iteration?
I have tried setting status code as a session attribute, however the request is not being sent and the token doesn't update, I tried doing a .doIf after the request exec, putting a doIf inside it's own exec and even playing around with transformResponse, all with no success.
Any suggestions how to approach this?
you can do something like what is outlined in
Gatling (performance test):how to perform task in background every x-minutes
However - is this really the scenario you want to model? How does the client you are simulating handle the 401? The scenario you are proposing only works if the client is in charge of manually handling its own refreshes.
I have a few components in one page.
Each of them fetches the same data from the server.
As a result, when the page loads, these components send the same request multiple times.
Is there any way to prevent this? Like caching the promise of the first request and returning that to the next coming requests (before the promise resolved)?
In order to make sure that the request is sent only once, you can keep track of the first HttpPromise you create, and on subsequent calls of the function, return that same promise.
This SO link might be what you're looking for.
When calling the $http service you can additionally supply a cache object. If you do so any additional requests will use the cached value. If the same cache is used then additional requests made before the first is resolved will not call the server but wait for the response.
$http.get(url, {cache:cacheObj})
Where cacheObj is from $cacheFactory
I am creating a login page in Angular. After login API call (POST), I get a token in response. In controller, I am trying to set this token in "common" header so that I can use it for authorization for all further API calls:
LoginSrv.authenticate($scope.credentials).then(
function(data){
$http.defaults.headers.common.Authorization = data.token;
$state.go('nextpage');
}
);
The next page there is again a POST API call. After this call when I check the request header in debugger I see that token in header. This response again navigate to third page (this time I am not setting header again). On third page when I call an API (GET or POST) the "Authorization" is not available in headers this time. I am not sure how this is removing by itself.
Given that your third request is cross domain, it appears your server is not correctly responding to the preflight browser OPTIONS request which is made to check what methods etc are available before it sends your request. It's not an Angular issue. One solution would be to configure your server to respond correctly to this OPTIONS request. This SO link (provided in the comments previously) explains in a bit more detail and discussions of potential solutions AngularJS performs an OPTIONS HTTP request for a cross-origin resource
I am using express-jwt to build a restful api. Now the client is making duplicate ajax calls, for the first one the initiator is angularjs and for the second one the initiator is other. The first one gets 204 as the response code and the second one gets 200 as the response code. I tried to debug to get to the source of this duplicate requests, but I am not able to.
Below is the header details for the one with 204 status code
Below is the header details for the one with 204 status code
Can any one suggest what could be the issue?
The first call is OPTIONS type. That's a pre-flight call which a browser sends if the page and api are not on same domain.
The purpose of this call is to deal with CORS. Backend usually needs to send the allowed request method types (GET, POST etc.). The browser will then send the real call if the desired request type is among those returned.
Here's a sample of the response headers.
You can ignore it for all intents and purposes. It does not contain any normally useful payload or return data.
Take a look at AJAX in Chrome sending OPTIONS instead of GET/POST/PUT/DELETE? for more info.
Those two requests are different one is OPTIONS and other is GET.
For cross-domain requests, setting the content type to anything other than application/x-www-form-urlencoded, multipart/form-data, or text/plain will trigger the browser to send a preflight OPTIONS request to the server.
You need to handle in the server when the request method OPTIONS , then you need to exit with out processing.