I am coming across this problem, i have a chat server which needs to communicate to the lambda service hosted in aws , but cloud front throws the following error.
BODY: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Bad request.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: h5kPdVnMXwh-P7e7mxQ5LL1gj9fAupp_MNAPxmxufI74W4WhE_MByw==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>
This is how my request goes in application.
const options = {
hostname: 'xxx.uat.com',
port : '443',
path: '/qa/addMessage',
method: 'POST'
};
const req = http.request(options, (res) => {
}
the chat server.js is hosted in ec2. what is the issue here?
I am facing the same error, I solved this by removing the body from my postman request.
require('http');
That is an HTTP client -- not an HTTPS client.
Specifying port 443 doesn't result in an HTTPS request, even though port 443 is the assigned port for HTTPS. It just makes an ordinary HTTP request against destination port 443.
This isn't a valid thing to do, so CloudFront is returning a Bad Request error.
You almost certainly want to require('https');.
I have seen this problem before. It happens due to the following reasons,
Invalid Protocol (using http instead of https)
Unknown http verb, make sure the endpoint is having the POST implemented in your case. If you are using API gateway, make sure you have deployed it.
In my case, I had the same problem as #Kireeti K, where I solved this by removing the body from my postman request.
it seems that Cloudfront throws an error if you send a GET request with a body, if you want to use the body, you will need to change your method to something else than GET, for me POST worked perfectly, the error was gone and I was able to read the body.
I encountered the same problem, this thread worked for me.
This error message:
"The request could not be satisfied. Bad Request."
is from the client and the error can occur due to one of the following reasons:
The request is initiated over HTTP, but the CloudFront distribution is configured to allow only HTTPS requests.
The requested alternate domain name (CNAME) isn't associated with the CloudFront distribution.
(In my case, the reason was #2).
For me the problem was that, I restarted the EC2 which changed the Instance ID, but my cloudfront origin was still pointing to the previous ID. So, once I changed it, it worked fine.
In my case, I have a client-side load balancer when calling CloudFront. As a result, I am calling CF by IP address instead of hostName.
I checked with Amazon AWS Support team, in this case, CF rejects the request and returns "403 Error, The request could be satisfied".
Related
Note: My site is in production mode, not testing. It is pending verification due to me adding an icon. This issue persisted before the verification was started.
Whenever my browser makes a request to Google for the one-tap widget or the pill, both requests return 400 Bad Request with an empty HTML page and the console is sent a message stating "The given origin is not allowed for the given client ID." I've gone onto the Google Cloud Console and checked my origins. I have only one listed, and it's the exact site I'm sending requests from my browser. My site also has its traffic proxied through Cloudflare if that makes a difference. In addition, I am using JavaScript callbacks (which work when used in PI#1).
Potential issue #1: The URLs are typed in wrong
When I insert localhost (I add https and http because I test with a HTTPS webserver locally using a Cloudflare origin certificate), the requests go through perfectly. However, the moment the requests are from my browser when it's not localhost, the requests fail. I've copied and pasted straight from the URL bar just to make sure that there's no typos or anything but the same results return.
Potential issue #2: The widget is making bad requests
I do open the URLs in other tabs (Which yield the same results from PI#1) and insert bogus URLs like example.com and thisisnotaurl.com to ensure it's not just dropping every request. Those requests return 403 Forbidden instead of 400 Bad Request.
Potential issue #3: The issue is browser specific
I've checked this issue on both Firefox and Microsoft Edge, both on the stable branches and completely up to date. I've disabled my ad block (UBlock Origin & Firefox built-in protection) to ensure they aren't messing with requests but everything except the crucial requests fail with 400 Bad Request. I have yet to test other browsers as I do not have them installed but I assume the same results come from them.
An example of the code can be found here: https://gist.github.com/Coder-Tavi/772ea25b16f3fa0b6b0e04739a1689dd.
The origins shown below are the exact website I am accessing. In addition, I've verified the client IDs are exactly the same as the ones I have added
Referrer Policy is improperly configured
The HTTP header Referrer-Policy controls the exact amount of data sent to servers regarding the origin of the request. In most cases, this is set to same-origin which means that the Referer header will send the origin to servers with the same origin.
Consider you have a webserver at example.com and another at web.example.com with a Referrer-Policy of same-origin. When example.com sends a request to web.example.com, the Referer header will contain the origin of the request, since it is the same origin. However, if example.com sends a request to google.com, the Referer header will not send any origin data, as google.com and example.com are not the same origin.
If we look at the requests, this directive is what we see
As such, we need to update the directive to allow the browser to send the origin in the Referer header. This can be done by inserting the following into the HTML of the current page.
<meta name="referrer" content="origin">
This meta tag will allow the browser to send the origin only to other webservers, and as such, Google will see the origin.
Consider the example above again. This time, when example.com sends a request to google.com, the request will contain a Referer header with the origin, as the directive allows for sharing of the origin. However, with this current policy, only the origin is sent, not the query parameters and other parts of the URL. With the following URL: https://example.com/test/123, google.com will only see https://example.com. The MDN Web Docs contain all the possible values and their effects.
A simple HTTP GET request.
When I put the URL into the browser bar, the results come back. (a small JSON object)
When I put the same url into Postman (https://www.postman.com/) I got the following 403 error back:
ERROR: The request could not be satisfied
403 ERROR
The request could not be satisfied.
Bad request.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: xxxxxxxxxxxxxxxx
What is causing this and how can I use Postman on API Gateway in AWS?
As a further clue to the puzzle - when I change the request type of 'post' in postman, I get the expected response for an undefined resource: {"message":"Missing Authentication Token"}
i'm trying to call my api flask on postman or on google chrome and i always get this:
POSTMAN :
Could not get any response
There was an error connecting to 192.168.1.178:5000/.
Why this might have happened:
The server couldn't send a response:
Ensure that the backend is working properly
Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General
Proxy configured incorrectly
Ensure that proxy is configured correctly in Settings > Proxy
Request timeout:
Change request timeout in Settings > General
Google chrome
Ce site est inaccessible
192.168.1.178 a mis trop de temps à répondre.
This looks like an issue with your flask server or could be related to the authentication method or missing data in your request.
What you can do is use the Postman Console to debug your outgoing request to the server.
What you can look for is:
Check the URL (in your case I think it's an IP address) of the request
Check the request method, for eg. 'GET', 'POST' - you might be calling the request with the wrong method.
Check the authentication method and credentials
Check the request body and headers.
And so on.. make sure you fulfill all the requirements of a complete request.
You can also put print statements in your flask server and see if the endpoints are being called (if it's a local server).
I've created an API with C++ and the following library: https://github.com/yhirose/cpp-httplib
In the API I've added a header to responses for CORS:
svr.Post("/suggest", [&dr](const Request &req, Response &res){
res.set_header("Access-Control-Allow-Origin","(origin here)");
(origin here) is the origin of the server making the request.
On the browser side I've also enabled an extension to bypass CORS. But when trying to make an AJAX request to the API, I still get this error in my browser console:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://192.168.1.10:10120/suggest. (Reason: CORS request did not succeed).
The AJAX request is done through a script written in the Tampermonkey extension to work on a specific website.
Do I need to modify headers on the server hosting the website? Have I done something wrong on the C++ side?
Also it might be important to mention that the code worked before. All I did was come back to it another day with a different local IP address (which i reprogrammed into the c++ API)
I tried it again to answer #sideshowbarker and it gave me a new error about self signed certificates. After adding the exception it worked.
I published an api to AWS with Visual Studio and using the template for AWS Serverless application project, for now I am testing the methods with postman, but all get methods that require a body are returning an error that mentions cloudfront in the response, I do not know if the issue is related to cloudfront or if it is the AWS HTTP 1.1 specification implementation that does not allow get requests with body:
Note:Get requests with body were a requirement from our client
RFC 7231 HTTP/1.1 specification says the following:
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD>
<BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Bad request.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID:
</PRE>
<ADDRESS></ADDRESS>
</BODY>
</HTML>
so my questions are:
are get request with body allowed in AWS?
How AWS deals with get request with body?
is there a way to make work get requests with body on AWS?
I saw almost the same question here:AWS GET request with body rejected by CloudFront
and they point to this document: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-lambda-non-proxy-integration.html that says if you send a get request with body it returns a 400 error, but the error I am getting is 403 error
so could you clarify a little bit more? or could you point to an amazon document that mentions the restrictions on get requests?
Many Thanks
GET request with Body is not allowed on CloudFront, You will get 403 if you send body, though RFC does not specifically say that you should reject GET with body but CloudFront doesn't allow that. The best option to pass body in GET request is by query string(Maximum length of a request, including headers and query strings 20,480 bytes).
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html
GET Requests That Include a Body
If a viewer GET request includes a body, CloudFront returns an HTTP status code 403 (Forbidden) to the viewer.