I tried using postman to test my springboot project. When I sent the request, postman made a 503 error, but when I sent the request in the browser, it successfully got a response.
How to solve this problem?
I had the same issue I resolved it like this :
Postman settings
go to the top right of your postman window Settings > proxy > use the system proxy
for my case I added another proxy so I had to desable it when making a local api call. good luck !
503 Service Unavailable clearly states the server is overloaded, you may be running out of memory. Try again or try to restart the server. The post method will say bad request only. So you should try restarting the server if it is yours, or retry after sometime if it is a 3rd party service.
And also can you check and make sure your postman proxy is turned off. Even that causes problems like these sometimes. Check that in proxy tab.
Related
I'm able to verify the webhook using glitch from the getting started:
https://glitch.com/edit/?fbclid=IwAR2YTjZuGGM9Hi6T_v1eZh_nV6_HY3RYn_8lll4gY1REa_bJy6ZAuq6tkKQ#!/whatsapp-cloud-api-echo-bot
my local server (in a subdomain with https enabled) has the same behavior as glitch and show "WEBHOOK_VERIFIED" on the log for the request:
/webhook?hub.mode=subscribe&hub.verify_token=xpto123&hub.challenge=123
but when try to verify my local server the request from meta does not reach the server.
chrome showing that the connection to the server is secured
After more tests I found that my local server was been blocked by the ISP, understood it after test with another connection.
I made my own server and had tried ngrok and other programs to run it from local host with https redirect but whatsapp doesn't allow the use of those programs.
In the end, my error was that the URL HAS to end in /webhook or else, it won't even send the request. Then it'll send a GET request and you have to return the hub.challenge query param after making sure that the provided token from them is the one you set up. This is my code using NodeJS
if(req.query['hub.verify_token'] === process.env.VERIFY_TOKEN) return res.status(200).send(req.query['hub.challenge'])
Good afternoon, let me ask
I created a service API using Laravel, but one of the API urls when I sent the response parameter was 403 or Forbidden. even though before it was fine, it worked smoothly. And I raised it to the server instead it became Forbide. Anyone know why? thank you for answering
If it is ok on local and getting a forbidden error on the server, the problem might be caused by the webserver application. please take a look at this link.
I am trying to test an ASP.NET Web Api locally using IIS Express. When I use Chrome and hit the url (localhost:5000/api/test, for example) the json displays fine, but when using Postman I keep getting unauthorized 401.2 when hitting the same url. The api controller has Anonymous access on the route.
On the error message, one of the likely causes is:
Integrated authentication is enabled and the request was sent through a proxy that changed the authentication headers before they reach the Web server.
Is Postman somehow changing the headers?
[2019 Update]
Got the same issue, I couldn't debug an ASP Core 2.1 API using Postman when running on the local machine using IIS Express. I kept on having "Could not get any response" despite it was working fine on a browser.
Following troubleshooting steps explained here PostmanLabs Github, I noticed into Postman console that this was coming from a certificate issue.
Disabling SSL Verification from Postman Settings > General allowed the request to pass through.
Looks like it's your proxy.
I haven't found the proxy setting in postman. So I deleted postman for Win and installed postman for Chrome. Possibly Postman gets the environment from Chrome.
Anyway the resolution is to use Postman for Chrome instead of Postman for Win.
I have a localhost WebAPI site up with IIS Express (HTTPS). Postman started to respond as expected to GETs and POSTs after I changed (in Postman)
File --> Settings --> Proxy
to: "Use the system proxy"
and turning on: "Respect HTTP_PROXY ...".
I had earlier set up a custom proxy that wasn't working with HTTPS.
I have been trying to get this resolved, without any success.
I have a webapp residing on my domain, say www.myDomain.com. I need to call a service which is present on another domain, say www.anotherDomain.com/service.do?
I'm using SproutCore's SC.Request.getUrl(www.anotherDomain.com/service.do?) to call that service.
I get an error that says, Origin www.myDomain.com is not allowed by access-control-allow-origin.
When I was in dev stages, and using sc-server, the issue was resolved using proxies. Now that I have deployed the app to an actual server, I replaced all the lines where I had set up the proxy with the actual domain name. I have started getting that error again.
The problem is that I CANNOT MAKE ANY CHANGES to the server on the other domain. All the posts that I have come across state that the other server on the other domain ought to provide access-control-allow-origin header and that it ought to support the OPTIONS verb.
My question is, is it possible for me to connect to that service using SproutCore's SC.Request.getUrl() method?
Additionally, the other posts that I have read mentioned that a simple GET request ought not to be preflighted. Why then are my requests going as OPTION instead of GET?
Thanks a ton in advance! :D
This is not a Sproutcore issue; it's a javascript Same Origin Policy issue.
If you can't modify the production server, you have no option but to develop your own proxy server, and have your proxy hit the real service.
This is effectively replacing sc-server in your production environment.
All this server would do is take the incoming request and pass it along to www.anotherDomain.com/?service.do.
You would need to make sure you passed all parameters, cookies, headers, the http verb, etc....
This is far from ideal, because now errors can occur in more places. Did the real service fail? Did the proxy fail? etc.
If you could modify the other domain, you could
1) deploy your SC app there.
2) put in the CORS headers so you could make cross domain requests
I am trying to implement Google Check out (GCO) on a new server, the process seemed to work fine on the old server.
The error from GCO integration console is the timeout error you might expect if there is load on the server and/or the response takes longer than 3 seconds to respond.
To perform a test (not integrating with my database), I have set some code to send an email to me instead. If I hit the https url manually, I get the email and I can see an output to the screen. If I then leave it as that, Google still returns the Timeout error and I don't get an email. So I have doubts as to whether google is even able to hit the https url.
I did temporarily attempt to use the unsecure url for testing and indeed I received the email, however this solution isn't the route we've developed for, so the problem is something to do with the secure url specifically.
I have looked into the certificate which is a UTN-USERFirst-Hardware which is listed as accepted on http://checkout.google.com/support/sell/bin/answer.py?answer=57856 . I have also tried to temporarily disable the firewall with no joy. Does anyone have any sugestions?
Good to hear you figured out the problem.
I'm adding the links below to add a litle more context for future readers about how Google Checkout uses HTTP Basic Authentication:
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#urls_for_posting
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#https_auth_scheme
http://code.google.com/apis/checkout/developer/Google_Checkout_HTML_API_Notification_API.html#Receiving_and_Processing_Notifications