When I was on AWS, setting up a 301 redirect for my website from www.example.com --> example.com involved simply creating a S3 bucket as a static website and set it up to redirect all traffic to example.com.
I don't see this option on Google cloud storage and I can't think of any way to do this with the HTTP load balancer.
Is the only way doing it involves patching my backend to notice addresses that start with www and strip the www and redirect ?
Google has a way of using buckets as backends for the http load balancer.
It is still in alpha but you can read about it and ask them to try it here. Use it with a html file to redirect like suggested here and my guess it should work.
Alternatively, I use Cloudflares free service, which allows for 3 free redirects. Saving you the trouble of configuring redirects in your backend. This can be done with some other CDN services as well I don't know which.
Related
I've been working on a project using Django as backend and React as a framework for the frontend. I've deployed this project in Pythonanywhere and it worked fine. Now, I would like to implement Next.js in my project but, unfortunately, Pythonanywhere does not support Node.js. So I decided to deploy my frontend in Vercel and let the backend in Pythonanywhere.
To achieve this, I plan to create a subdomain that handles the API request. In the domain DNS panel, each domain and subdomain respectively will point to different sites. It'd look like this:
www.example.com (Pointing to Vercel, where the React app is hosted)
api.example.com (Pointing to Pythonanywhere, where the backend is hosted)
I've searched about this in Google and it should work. But, here comes my question, is this the best approach or should I consider other options?
Here is a post that is related to this one. In the post, the author plans to deploy both: backend and frontend on GCP.
Thank you in advance for your time and answers!
The setup you described is pretty standard and it will work perfectly. All you need is to take care of the following points:
Make sure "www" and "#" (aka root) points to Vercel's using DNS configuration. It should be an A record to 76.76.21.21 in the root domain and a CNAME record to cname.vercel-dns.com on the "www" subdomain. Remember to redirect the domains for optimal SEO score.
The DNS record for api.example.com should point to the other provider. You need to check if they require an A or CNAME record. They may require additional DNS records (CAA?).
CORS: Notice that example.com should trigger requests to api.example.com. Your CORS configuration should account for that. CORS is a whole different discussion but I will point you in the right direction. You need to check Next.js custom headers and CORS guides.
If you face any issues on Vercel, you can contact their support channel.
I'm trying to implement URL redirects from http to https as described by [https://cloud.google.com/load-balancing/docs/https/setting-up-traffic-management][1] but I'm getting ERR_TOO_MANY_REDIRECTS
I have a storage bucket with a very simple HTML page.
I have an external HTTP load balancer in front of it. Static IP address. SSL cert. I managed to connect everything so that both http and https requests for the site load the contents of the bucket.
I tried to add the HTTP redirect as per the document:
Changes 'Host and path rules' from 'Simple' to 'Advanced...'.
The default route still points to the bucket
I added a new route. Host is 'www.example.com. The default path rule points to the bucket. The second path rule matches /* and does a prefix/HTTPS redirect as described in the above link.
Once the config is saved, either http or https requests to www.example.com results in ERR_TOO_MANY_REDIRECTS
What am I doing wrong? Really appreciate any help you can provide.
[Backend configuration][2]
[Frontend configuration][3]
[Host and path rules][4]
[Redirect path rule][5]
[1]: https://cloud.google.com/load-balancing/docs/https/setting-up-traffic-management
[2]: https://i.stack.imgur.com/lkhUF.png
[3]: https://i.stack.imgur.com/FYst0.png
[4]: https://i.stack.imgur.com/zsTOX.png
[5]: https://i.stack.imgur.com/2tEDE.png
FYI - someone in Google Groups pointed out that I needed 2 load balancers. 1 to terminate the HTTPS traffic and the second to redirect the HTTP traffic. Works like a charm.
I am using guthub pages to host a simple website with a custom domain. To manage the the DNS I am using CloudFlare.
I had pages rules setup on CloudFlare for forwarding to my google drive file:
example.com/pdf Foreward rule code 301 https://drive.google.com/file/d/ZZZZZZZZZZZZZZZZZZZ
A while back I enabled HTTPS for my custom domain. Domain is assigned to the guthub page using CNAME and on the github settings page I have enabled Forced HTTPS
I only recently noticed my short links to the google drive files were down.
Is this due to HTTPS? Can replicate forwarding to foreign domain effect without compromising on HTTPS?
You need to make sure that site-wide SSL is reflected in the rule, because Cloudflare first enforces the SSL and only then processes the rules.
https://example.com/pdf 301 https://drive.google.com/file/.........
i recently migrated my application to AWS and setup a cname for www.domain.com and a redirect for the domain.com to redirect to www.domain.com.
The problem is, an external service was using a path on the naked domain.com (something like domain.com/external/service/) But with the redirect all HTTP POST data is being dropped with the redirect and i cant change the url that the external service is calling.
To fix this, i have setup my naked domain on route53 to point to my elastic load balancer where my app is located. I set up an A record pointed at my elastic load balancer using an alias.
Its been two days now and my naked domain still redirects to www. and therefore the external service is down. Any ideas on what i could do?
I am taking a long shot - there are different possible problems:
You are forwarding naked domain via A record to ELB, but your EC2 instace (say Apache) is still doing a redirect (not DNS, but http 301) back to www.
Check the DNS TTL. If the TTL is too large (say 48 hrs), then it takes that time. You need to wait longer.
Is Route53 fully managing your DNS? One possibility is that, somebody else like Godaddy is still doing the DNS for you - so nobody is contacting Route53 for the change to reflect.
With AWS services we have the Web application running from the S3 bucket and accessing the data through the REST API from Load Balancer (which is set of Node.js applications running on EC2 instance).
Currently we have specified URL's as following:
API Load Balancer: api.somedomain.com
Static Web App on S3: somedomain.com
But having this setup brought us a set of problems since requests are CORS with this setup. We could workaround CORS with special headers, but that doesn't work with all browsers.
What we want to achieve is running API on the same domain but with different path:
API Load Balancer: somedomain.com/api
Static Web App on S3: somedomain.com
One of the ideas was to attach the API Load Balancer to the CDN and forward all request to Load Balancer if query is coming on the "/api/*" path. But that doesn't work since our API is using not only HEAD and GET requests, but also POST, PUT, DELETE.
Another idea is using second EC2 instance instead of S3 bucket to host website (using some web server like nginx or apache). But that gives too much overhead when everything is in place already (S3 static content hosting). Also if using this scenario we wouldn't get all the benefits of Amazon CloudFront performance.
So, could your recommend how to combine Load Balancer and S3, so they would run on same domain, but with different paths? (API on somedomain.com/api and Web App on somedomain.com)
Thank you!
You can't have an EC2 instance and an S3 bucket with the same host name. Consider what happens when a web browser makes a request to that host name. DNS resolves it to an IP address (or addresses) and the packets of the request are delivered to that address. The address either terminates at the EC2 instance or the S3 bucket, not both.
As I understand your situation, you have static web pages hosted on S3 that include JavaScript code that makes various HTTP requests to the EC2 instance. If the S3 web pages are on a different host than the EC2 instance then the same origin policy will prevent the browser from even attempting some of the requests.
The only solutions I can see are:
Make all requests to the EC2 instance, with it fetching the S3 contents and delivering it to the browser whenever a web page is asked for.
Have your JavaScript use iframes and change the document.domain in the the web pages to a common parent origin. For example, if your web pages are at www.example.com and your EC2 instance is at api.example.com, the JavaScript would change document.domain to just example.com and the browser would permit iframes from from www.example.com to communicate with api.example.com.
Bite the bullet and use CORS. It's really not hard, and it's supported in all remotely recent browsers (IE 8 and 9 do it, but not in a standard way).
The first method is no good, because you almost might as well not use S3 at all in that case.
The second case should be okay for you. It should work in any browser, because it's not really CORS. So no CORS headers are needed. But it's tricky.
The third, CORS, approach should be just fine. Your EC2 instance just has to return the proper headers telling web pages from the S3 bucket that it's safe for them to talk to the EC2 instance.
Just wanted to add an additional bit to the answer that, if we go with CORS approach and preflight requests adds an overhead to the server and network bandwidth, we may even consider adding header "Access-Control-Max-Age" to the CORS response
Access-Control-Max-Age