I have developed my API and registered in mule API Manager.
When my API is down and trying to hit the API from Postman tool getting below error.
<html>
<head>
<title>504 Gateway Time-out</title>
</head>
<body bgcolor="white">
<center>
<h1>504 Gateway Time-out</h1>
</center>
<hr>
<center>nginx</center>
</body>
</html>
Ideally it should be 503 – Service unavailable. Any options to get error code 503 instead of 504 ?
If you API in API manager is down, there is nothing you can do. If your backend implementation is down you could do something will policies to override the status code.
But as your API in API manager is down, there is nothing in your control.
504 is still technically valid as nginx is acting as a proxy and it cannot reach your API.
But I would not worry about it. all API client should handle 5XX status code the same. As in 'Server Error' and can possibly be retried later.
Also with API down in API manager, the 504 should take a while to get a response back. So I would probably set a decent request timeout before reaching that point.
That really isn't in your control. The difference between 503 and 504 is that 503 means that your app-server has issues, while 504 means that the gateway you're using has issues.
For example, if I am using nginx as a gateway, and I'm redirecting to some app server. If the app server is down, then nginx will return 503.
If, however, the app server is unresponsive, or if nginx itself is failing (due to load, or other issues), the response will be 504.
In general, you shouldn't be worried about what the response is. 5xxs are treated roughly the same in most situations, and they mean server issues.
Related
We are encountering errors when trying to use a web application, iframe, and proxy port in colab in Chrome.
First, we pick an unused port, then set up a server on that port.
Then, we create an iframe that connects to this proxy url:
server_url = eval_js(f"google.colab.kernel.proxyPort({port})")
The iframe itself is loading, but we see tons of network errors and the server is not properly connecting in colab. Many of the errors we see are grouped like this, with a 500 and 401, and don’t think we should be seeing this. It appears that there is a service worker intercepting our fetch call (a grpc-web+protobuf call), and when it encounters the 401 error from the server-side proxy, it translates it into a 500 that our application code sees. Are there any other details that we should know about in regards to the proxy/service worker that seems to be intercepting the calls?
Attached it a screenshot of Chrome's dev tools, showing the 500 and 401 calls. As you can see, a service worker handles the initial request, and appends a ?authuser=0 to the request before it goes to the server-side proxy.
The 500 response is empty, and the 401 response is below:
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 401 (Unauthorized)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}#media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/logos/errorpage/error_logo-150x54.png) no-repeat;margin-left:-5px}#media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/logos/errorpage/error_logo-150x54-2x.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/logos/errorpage/error_logo-150x54-2x.png) 0}}#media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/logos/errorpage/error_logo-150x54-2x.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
</style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>401.</b> <ins>That's an error.</ins>
<p> <ins>That's all we know.</ins>
It looks like the first unary grpc-web call will go through, but subsequent calls will fail - in our use case, the next call is server-streaming, but later unary calls also fail, so it doesn't seem to be specific to expecting h2 server-streaming responses.
Colab link:
https://colab.research.google.com/drive/1FGDlUi3Ibtffb9hoYCp27WCe7JLpQRl7?usp=sharing
We're confident that our server isn't sending the 401 reply (as it would use a grpc-status instead), and as far as we can tell, it doesn't even get the request, much less have the opportunity to respond.
We would expect to be able to connect to the server and continue communication.
I am looking at my Google App Engine dashboard, I have a .NET Core Web API deployed and am processing somewhere between 5-10 requests per second, but I am also reporting a handful of 400 errors from the GCP HTTP Load Balancer and I don't know why. I look at the Google Load Balancer logs and I also see a bunch of 400 errors on my primary POST endpoint. This only happens on the POST endpoint. I try to see the full body of the HTTP Request but I can't seem to find it, it looks like Google doesn't log it by default.
I have a .NET Core API running on Google App Engine Flex connected to Google Cloud SQL running PostGresSQL.
How can I get more detail either from the Load Balancer to find out exactly what requests are coming in and what is happening? I have attached a sample of the requests/400 status responses below.
Thanks in advance.
See Google App Engine Requests VS 400 errors graph
See HTTP 400 Errors with HTTP Load Balancer
I have two cloud services up and running.
frontend (URL: https://frontend-abc-ez.a.run.app/)
backend (URL: http://backend-abc-ez.a.run.app/)
Frontend is calling the backend through a nuxt.js server middleware proxy to dodge the CORS problematics.
The call is coming through - I can see that in the backend log files. However the response is not really coming back through because of CORS. I see this error in the console:
Mixed Content: The page at 'https://frontend-abc-ez.a.run.app/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://backend-abc-ez.a.run.app/login'. This request has been blocked; the content must be served over HTTPS.
What I find weird is that I configured the backend url with https but it is enforced as http - at least that is what the error is telling me. Also I see a /login path segment in the unsecure URL. Why is that? I never explicitly defined that endpoint. Is it the security layer proxy of the run service itself?
Anyway - I need to get through this properly and am having a hard time to understand the source of the problem.
For some reason as I rechecked the applications today in the morning everything went fine. I have really no idea why it is working now. I did not change a thing - I waited for the answers here before I'd continue.
Very weird. But the solution so far seems to be waiting. Maybe Cloud Run had some troubles.
We have a WCF Service that is working fine, there are 4 customers using this service without problems, but I have this one customer who is complaining that he can't call the webservice anymore for the last few days.
We did not change anything since October and he also claims he did not change anything.
As I said, I have other customers using this service just fine and we also can call the service from SOAP UI. We even tried to create a new isolated machine in AWS and call the service in order to make sure it is not something like a firewall issue blocking the communication from outside our network.
For what I can see from the stack trace he sent me, this customer uses Sonic ESB to call our service. I really don't understand how Sonic ESB works but my guess is that the error is caused by Sonic ESB, not my service. It is like it creates an "adapter" in between his application and my service.
Which led me this following conclusion:
1) Looking at his request XML (he sent me) I can see that it does not match the WSDL I have provided, for instance:
(I have changed few names and values for obvious reasons)
<CreateOrderGatewayCompanyName> --> This would be just CreateOrderGateway
<header> --> this header seems specific to Sonic ESB, nothing to do with us
<user>123414714</user>
<idProcess>5411251</idProcess>
<channel>EB</channel>
<ip>[ip number here]</ip>
<sessionId>1fd5a3f4d8f4dsa5f4dsaf4dsf1da5.xyz</sessionId>
</header>
<body>
<idCampania>xyz</idCampania> --> This would be "CampaignId"
...
<order>
...
<fecha>2016-12-21</fecha> --> This would be "Date"
...
</order>
</body>
</CreateOrderGatewayCompanyName>
So I can only conclude that somewhere in the process, the ESB will convert this weird XML in the proper SOAP request format my service is expecting.
2) Looking at the exception stack trace he sent me, I can see this 404 error:
<?xml version="1.0" encoding="UTF-8"?>
<exception xmlns="http://www.sonicsw.com/sonicesb/exception">
<message>Exception while retrieving soap envelope from response:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Not Found</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Not Found</h2>
<hr><p>HTTP Error 404. The requested resource is not found.</p>
</BODY></HTML>
</message>
<class>com.sonicsw.xqimpl.invkimpl.wsif.providers.axissoap.SoapProviderInvocationException</class>
<detail/>
<stackTrace><![CDATA[org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
...
And here is the thing, this 404 HTML code that he is getting as a response DOES NOT come from my server because we use IIS 8.5 and the 404 error page of IIS does not look like this one, the HTML is different and the message is different as well. It would be something like:
“404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed,..”
So does anyone know if this Sonic ESB actually creates an adapter or proxy in the middle of the applications? And if someone already have experienced an error like this what would be the cause? I'm 100% positive my service is working fine.
Did your customer sent the actual soap request that is being sent?
He can enable the actual webservice invocation (the easiest way is to do it from the admin console).
http://knowledgebase.progress.com/articles/Article/S6498
After knowing the exact soap request that it is being sent, it will be easier to debug.
Also I recommend that you enable for some minutes the traces of requests in your server when he tests to discard that any other modifications are done in the middle.
It turns out that a network trace (wireshark) on my server revealed that my customer's proxy was modifying the "Host" of the request, for instance, instead of
Host: ourdomain.com
It was modified like
Host: proxy.customer.com:8080
So when this request arrived at the IIS server, the binding was configured to "ourdomain.com" and then it dropped the request. For some weird reason, a guy named "Microsoft HTTPAPI" returned the reply with that 404 error page my customer was getting on their application.
So we have fixed the problem changing our IIS bindings because I don't want to wait my customer to investigate what the hell is his proxy doing with the host name.
I created an instance group through an instance template, and aligned this instance group to a backend service which is used by a http load balancer.
Now when I open a url to an instance vm from the instance group I created, I can do GET POST and DELETE requests and all of the requests are fast, and everything works as expected.
When I open up the url to the static IP for the load balancer. I can do GET and POST requests, but DELETE requests throw a 400 BAD REQUEST with a response page saying:
That’s an error.
Your client has issued a malformed or illegal request. That’s all we
know.
Other load balancer issues:
The site is quite slow through the load balancer. Perhaps
there is a setting I'm missing, I'm pretty sure I set everything to
us-central-1b.
Sometimes the site doesn't even show up. It will work for http, but then
it won't work for https and visa versa. The load balancer has very strange
behaviour.
My VM api access is set to This instance has full API access to all Google Cloud services
I'm using Django as my api layer, I turned on debugging on this host and saw that the DELETE requests weren't even coming through when making requests through the loadbalancer static ip. Is there a firewall setting I'm missing?
Please help me make this fast again and allow the DELETE requests to happen.
Thanks!
Are you sending anything in the body of the request?
Google load balancer will respond with 400 BAD REQUEST if you try to send anything in the body. Easy way to check if this is the problem is fire up Chrome Developer tools and check the Request Payload section is empty/doesn't exist.
The HTTP spec doesn't explicitly say wether you can pass anything in the body so this isn't wrong, just undefined.
Is the load balancer slow for all requests or just pages with lots of elements on?