Postman API call 502.3 error when doing collection running, but works when run manually each API - api

I’m new in API testing please bear with me.
I’m using Postman to test our API. I run a bunch of request using run collection on the entire collection but it always returns 502.3 Error on a random POST request, but when I tried to request it standalone it has no issue and it returns the POST request that I’ve selected. It only happens when I run collection test on the entire collection and it returns 502.3 randomly.
502.3 Error when running collection test on the entire collection.
No Issue when run request individually
On the console it says
JSONError: Unexpected token ‘<’ at 1:1 <!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/ ^
Checking the IIS Logs it shows that it is a 502.3 with Error code 12030. Upon doing research it means it is a ERROR_WINHTTP_CONNECTION_ERROR
“The connection with the server has been reset or terminated, or an incompatible SSL protocol was encountered. For example, WinHTTP version 5.1 does not support SSL2 unless the client specifically enables it.”
Any idea on how to fix this? Is this a connection issue? The server on which I’m requesting API is on a VPN.

Related

Receiving the below mentioned error in JMeter while using Delete Request. Unable to find why this error occurred

Notice: Trying to get property of non-object in /var/www/maps/api/place/DeletePlace.php on line 42
The error means that the application you're testing tries to read some property from something not being an object.
If the behaviour can be reproduced using a real browser it indicates a bug in your application
If it happens only with JMeter and isn't reproducible with the browser you need to cross check the request JMeter sends using View Results Tree listener and the request the browser sends using "Network" tab of your browser developer tools - the requests must be exactly the same (apart from dynamic parameters which need to be correlated)
The most common mistake when it comes to API testing using JMeter is that people forget to add HTTP Header Manager and configure it to send a valid Content-Type header

Getting a 401 http response (sometimes) while request is proper

i've been facing a problem lately and i don't know how to handle it, or even what the problem might be coming from.
Tools:
-MYSQL(for data base)
-JAVA EE web application(to service as back-end)
-Jersey 2.26 dependency (to service as API on top of web application /CORS filter implemented)
-Apache Tomcat/7.0.69 ( as web server where web app sets )
-Angular 4 ( as website and client to the API)
-CentOS Linux release 7.3 (Core) (Server operating system )
Problem:
once the request is sent to the API ( to a specific secured Endpoint ) lets call it customers, Sometimes the response is 401 Unauthorized, and in other times it works just fine, from the angular website for instance, if press f12 and follow the requests, i send the same request again ( for the one i got 401 for ) but this time it works, the JWT is valid and it works just fine, and its not that there is too many request going to the server, even if its few sometimes i get 401, but most of the time it works great.
the only thing in the code that can return 401 is the authentication filter, which checks the validity of token, but it looks fine to me.
i checked this article that talks about 401 response, but still, its hard for me to grasp the idea why it works good sometimes and not work other times for the same request. i get the 401 while checking with the website and also with checking with postman. so i guess it's not a cache or cookies thing, but i might be wrong to assume this.
any ideas on what might be wrong ? or where should i be checking for bugs or errors ?
Thanks allot
Set tomcat security to false .

Possible proxy issue with WSO2 API Manager

Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.

How to get details exception from published Web Api

Is there any way to get detail exception & Stack trace from deployed Web Api?
Even if I deployed in Debug mode, do I get detail error traces?
I got bellow message from server API
"message": "Processing of the HTTP request resulted in an exception.
Please see the HTTP response returned by the 'Response' property of
this exception for details."
This happened only in server, same code running perfectly in local machine.
Did you check the content-type for the request that you are performing?
Sometimes this error comes because you don't specify this value, e.g. "application/json" in the headers of the request.
If your scenario is to have a central place to log any exceptions that happen when requests are being processed, then I would suggest to take a look at 5.1 version of Web API (released couple of days back), specifically the Global Error Handling feature.
http://www.asp.net/web-api/overview/releases/whats-new-in-aspnet-web-api-21#global-error
If you go to the above page,you should notice ExceptionLoggerContext which gives you details of the exception.
About Web API versions 5.0 and before:
In these versions there was no really a central place for catching exceptions. ExceptionFilterAttributes caught exceptions for only certain areas of Web API.

Magento REST API not working in PHP

Whenever I try to call Magento's rest resources via PHP, I get an HTTP 500 Internal Server Error. My link is, in accordance to Magento's REST API, http://mymagento.com/api/rest/products.
Everything is set up properly and whenever I try to access it via the browser, the response is a page with the XML data I want. Same thing goes for the RESTClient plugin for Firefox.
I also get the internal server error whenever I try to do an authorised request as a customer.
Does anyone know why this is happening? I ran out of ideas an hour ago or so.
If you just got that problem (only) then,
500 errors in the HTTP cycle
Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:
Obtain an IP address from the IP name of the site (the site URL
without the leading 'http://'). This lookup (conversion of IP name to
IP address) is provided by domain name servers (DNSs).
Open an IP socket connection to that IP address.
Write an HTTP data stream through that socket.
Receive an HTTP data stream back from the Web server in response.
This data stream contains status codes whose values are determined by
the HTTP protocol. Parse this data stream for status codes and other
useful information.
This error occurs in the final step above when the client receives an HTTP status code that it recognises as '500'. (Last updated: March 2012).
Fixing 500 errors - general
This error can only be resolved by fixes to the Web server software. It is not a client-side problem. It is up to the operators of the Web server site to locate and analyse the logs which should give further information about the error.