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
Related
This question already has an answer here:
Google Maps - calling the API directly from javascript vs using the SDK
(1 answer)
Closed 12 days ago.
If my website origin is notexample.com, and If I load library from example.com/script.js, can this script make fetch request to example.com and not get CORS prevention error?
I attempted to make the request, but I was met with a CORS error. I am quite curious as to how Google went about implementing its API. With Google Maps, for example, you are unable to directly request an API endpoint or else you will receive a CORS error. However, if you use Google Maps client library that is loaded from Google servers/domain, you are able to make the request successfully. It's an interesting security measure that Google has taken, and it's something that I'd like to take some time to research further.
The origin of the script (https://example.com) is irrelevant, because cross-origin script embedding is always allowed:
Here are some examples of resources which may be embedded cross-origin:
JavaScript with <script src="…"></script>. [...]
What matters is the Web origin in which that script is loaded. If you load that script in the context of https://notexample.com and the script sends a (cross-origin) request to https://example.com, the Same-Origin Policy will kick in.
And unless https://example.com is configured for CORS to allow requests from https://notexample.com, things will not work as expected.
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.
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?
My server side setup is like this : I have a google compute engine instance running nodejs server. It sits behind https load balancer.
So the issue is that if OPTIONS type request is sent with body(payload) to load balancer ip, it sometimes fail with 502. I have checked that in all these requests, node server is returning and logging correct responses. It works perfect if the request body is left empty.
However, when I directly hit GCE's ip, it works fine whether or not request body is there or not.
For e.g
this is the load balancer ip (with ssl enabled)
OPTIONS https://130.211.14.60/health
this is the direct GCE machine ip (without ssl)
OPTIONS http://104.199.159.212:8002/health
I have checked by sending requests multiple times(literally hundreds of times) using Postman app.
And this issue is only with DELETE and OPTIONS type requests. GET/POST/PUT works perfectly fine.
Is there anyone who can point me what the issue could be and how to solve it.
From Google's docs -
The HTTP(S) load balancer does not support sending an HTTP DELETE with a body to the load balancer. Such requests will receive an error message: Error 400 (Bad Request)!! Your client has issued a malformed or illegal request. Only DELETE requests without bodies are supported.
More info here.
This feature is now supported by Google Load Balancer, released in Dec '18.
More info here.
I have created a website http://moviesnight.club using THIS API everything is working fine on localhost, but when I have uploaded it into hosting the movie posters are being loaded and error on console [Failed to load resource: the server responded with a status of 403 (Forbidden)]. But all other thing are ok. So is there any suggestion how to make it work?
This is how it looks on HOSTING (moviesnight.club)
This is how it looks on localhost
You are not adding an api key to your request
From the OMDb website usage this is what your url needs to be
http://img.omdbapi.com/?apikey=[yourkey]&
The website also provides this link to obtain your api key
http://beforethecode.com/projects/omdb/apikey.aspx