“This request has been blocked; the content must be served over HTTPS.”, I am getting this error when trying to reach my Beanstalk (spring boot) api from Cloudfront (angular app on s3)
I am quite new to aws and have spent some time on this. I have tried How to allow HTTPS on Elastic Beanstalk application and followed most guides online.
Listeners for load balancer:
My target group is unhealthy for some reason (not sure if that info is useful).
I have allowed traffic on the ports in the security groups (suggested in other questions and guides).
And just recently tried creating a distribution in CloudFront using the load balancer.
What am I missing or doing wrong? Any help would be much appreciated, thanks.
- Since the browser requires HTTPS for secure contexts, make sure the Spring Boot API is available over HTTPS. From your load balancer configuration, it appears you have an HTTP to HTTPS redirection rule on port 80, but this might not be working as expected. Check the backend API URL if it is served over HTTP or HTTPS.
- Double Check you Backend API URL on Angular side if it is http://backend-api.com or https://backend-api.com
- You mentioned that the target group is showing as unhealthy. The ELB considers the target group healthy based on a successful health check. Ensure the health check path is correctly configured in the target group settings. If it’s incorrect or not available, your instances will be marked as unhealthy. For example, if the health check is set to /, and your application serves content on /api, the health check will fail.
- Sometimes redirection rules can cause a 3xx (redirection) response, which might be returned by your application during the health check process. If your load balancer is configured to redirect HTTP requests to HTTPS (as in your case), it’s possible the health check is receiving a 3xx status code, which, by default, could be treated as a failure unless explicitly included in the success codes. In your case, adding the success codes 200-399 under EC2 > Target Groups > Health Checks would accommodate both the 200 range (successful responses) and 300 range (redirection responses), allowing the health check to pass even when a redirection occurs. refer to this image
You can also add these configurations directly from your application source code by adding this code under .ebextensions/health_check.config:
option_settings:
- namespace: aws:elasticbeanstalk:environment:process:default
option_name: HealthCheckPath
value: "/health-check"
- namespace: aws:elasticbeanstalk:environment:process:default
option_name: MatcherHTTPCode
value: "200-399"
Faran Khalid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
The redirect rule is unhelpful here, because the browser is preventing the request from even getting to the load balancer, so the redirect rule is not being triggered. The web browser is saying “this is a secure website, but it is trying to make insecure HTTP calls to an API, so I have totally blocked the API call”.
For the redirect to work, the browser would have to allow the insecure API call to happen first, at which point the load balancer would then return a redirect, essentially telling the web browser to try again using a secure URL this time.
You need to change your front-end code to ensure it is only making HTTPS calls to the backend API.
My target group is unhealthy for some reason (not sure if that info is useful).
It’s not the cause of the issue you are currently seeing, but once you get the API calls working from the front-end you are going to get error responses from the backend until you fix the target group health checks. It is absolutely critical that you get the target group health checks working so that the load balancer will actually route the requests to your target server(s).