Let's say I have requests coming into my IIS site on two different ports. Can I direct one port to serve www.website.com and another to www.website.com/subfolder?
I'm trying to do some georouting without having more than one webserver or site. I have AWS Route-53 set up to send traffic based on region to different load balancers that will take traffic from one region and send to port 2000, and from a different region to port 2001. www.website.com has content geared for the first region, but www.website.com/subfolder is our content for the other region. Since AWS can split up the traffic for me based on location and send to different ports of my choosing, is there anyway to use that to route or redirect requests to different folders on the same site?
EDIT: I think the way to do this is with a URL redirect rule, with a condition for {SERVER_PORT} specifying the port like so:
Match URL: Matches Pattern: .*
Condition: {SERVER_PORT} Matches Pattern 2001
Action Type: Redirect URL: subfolder/{R:0} Type: Permanent (301)
This should route everything coming in on port 2001 to my subfolder but not the traffic on other ports, correct? The site CMS already arranges everything so that www.website.com/(anything) and www.website.com/subfolder/(anything) will display the same content, with changes appropriate to the region.
So this works with the Redirect rule I assigned above. Since it broke a few includes, like stylesheets and whatnot, I also added some exclusions with {PATH_INFO} tag, and there needed to be a rule to exclude URLs that already had subfolder/ in them, using the {HTTP_URL} condition, to prevent the redirect from looping forever and giving you www.website.com/subfolder/subfolder/subfolder.... etc.
Related
Issue:
I have a naked url which works, but "www." + the naked url yields a 404 error. I'd like to point the www version to the naked version.
Context:
I have a serverless website, deployed on google cloud run.
I have a domain name registered through google domains, let's call it foo.bar.
Google cloud run provides two types of resource types for me to provide to google domains: A and AAAA, which are ipv4 and ipv6 addresses respectively.
I have added these A and AAAA records as custom records to google domains. With google domains, the hostname field is left blank, which is equivalent to #. From my understanding, this means that when someone types foo.bar, they get directed to these ipv4/ipv6 addresses. This works as intended.
But if I type www.foo.bar, I get a 404 error. As far as I know, www.foo.bar and foo.bar are not equivalent, and so there is no expectation that these two things should work unless explicitly instructed to. So I have tried two approaches to link these, as follows:
Added the A and AAAA resources, but specified www as the hostname, rather than blank. I would expect this to point www.foo.bar to the ipv4/ipv6 addresses too.
Added a CNAME resource, which specifies www.foo.bar as the hostname, and foo.bar as the data. I would expect this to redirect www.foo.bar to foo.bar, which points towards the ipv4/ipv6 addresses.
I would expect both of these to work equivalently, yet neither of them work. I feel like I am misunderstanding what is going on when managing these records, or that google domains is more opaque about what it is doing than I'd like.
Is my understanding of what should happen incorrect? And how can I properly set up the www extension?
You must create Cloud Run custom domains for each hostname. One for example.com and another for www.example.com. You must also create the DNS resource records, which you mentioned that you did complete.
I have two backends I want to serve from one Host. One from host.domain.com and the other from host.domain.com/path. The first frontend rule is straightforward: Host:host.domain.com.
The second is giving me some trouble. Based on the documentation I believe I should be using Host:host.domain.com;PathPrefixStrip:/path. This returns a 200 on host.domain.com/path, but when I click the link to somepage.html, it sends me to host.domain.com/somepage.html, so it returns a 404. If I go directly to host.domain.com/path/somepage.html it returns a 200. The link to somepage.html behaves correctly when I go directly to host.domain.com/path/index.html.
Are my assumptions/interpretations of the documentation incorrect or is this not an issue with Traefik at all?
This isn't really specific to traefik, any virtual path based reverse proxy that doesn't rewrite the contents of the web page returned (and few do this) have problems when the contents of that web page have absolute paths. The web page needs to either know about the "/path" and modify all the links it gives you, or use relative links, without a leading "/". This should be fixed within your website, web application, or hopefully a configuration for a web application. Depending on the application, once reconfigured, you may need to adjust the traefik rule to just "PathPrefix" instead of "PathPrefixStrip".
You should use a PathPrefix instead a PathPrefixStrip . The Strip rules remove the path before presenting it to the backend.
Since the path is stripped prior to forwarding, your backend is expected to listen on /.
I have a complex web app at example-app.com, hosting fully on AWS using ELB and Route 53 for DNS. It's a Rails app.
I'm running an experiment that I'm using in the rails app, at example-app.com/test. I want to set up new-domain-app.com, to point at example-app.com/test, and have the URL cloacked to always be new-domain-app.com. It's a single page site, so it shouldn't require any navigation.
I'm having a lot of trouble figuring out how to set up my DNS on Route 53 to accomplish this. Does anyone have good ideas on what this Route 53 configuration should look like?
AWS offers a very simple way to implement this -- with CloudFront. Forget about the fact that it's marketed as a CDN. It's also a reverse proxy that can prepend a fixed value onto the path, and send a different hostname to the back-end server than the one typed into the browser, which sounds like what you need.
Create a CloudFront web distribution.
Configure the new domain name as an alternate domain name for the distribution.
For the origin server, put your existing hostname.
For the origin path, put /test -- or whatever string you want prefixed onto the path sent by the browser.
Configure the cache behavior as needed -- enable forwarding of the query string or cookies if needed and any headers your app wants to see, but not Host.
Point your new domain name at CloudFront... But before you do that, note that your CloudFront distribution has a dxxxexample.cloudfront.net hostname. After the distribution finishes setting up (the "In Progress" status goes away, usually in 5 to 20 minutes) your site should be accessible at the cloudfront.net hostname.
How this works: When you type http://example.com into the browser, CloudFront will add the origin path onto the path the browser sends, so GET / HTTP/1.1 becomes GET /test/ HTTP/1.1. This configuration just prefixes every request's path with the string you specified as the origin path, and sends it on to the server. The browser address bar does not change, because this is not a redirect. The host header sent by the browser is replaced with the hostname of the origin server when the request is sent to the origin.
What you are trying to do is not possible. Route53 is a DNS system, and you can not configure a hostname (e.g. new-domain-app.com) to point to URL (e.g. http://example-app.com/test) using DNS.
However, you are probably using a wrong tool for the job. If example-app.com/test is indeed a simple, static, single page site, then you do not need to host it inside Rails app. Instead, you can host it on AWS S3 bucket, and then you can point new-domain-app.com to that bucket using Route53.
See the following for details:
http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html
DNS knows about Domains, not url's. DNS simply converts names to IP addresses.
You can't do what you are asking for just using DNS and ELB, however, what you can do is have a seperate VHOST for new-domain-app.com that points to your example-app.com site and accomplishes what you want using some sort of redirection rule that only fires for new-domain-app.com.
I'm not sure that this qualifies as an SO question, and more likely is a serverfault question. Specifics about your webserver and OS platform would be helpful in getting more specific advice.
So here's some details:
You already have example-app.com setup and working
You create a CNAME entry pointing new-domain-app.com to example-app.com or you can make an A record pointing to the same IP. If you already have example-app.com pointing to a different IP address, then use a subdomain (test.example-app.com) to isolate it.
Setup a new vhost on your server that basically duplicates the existing vhost for new-domain-app.com. The only thing you need to change is the server name configuration.
Why does this work? Because HTTP 1.1 included the HOST header that browsers send along, and web servers use in vhosting to determine which virtual host to route an incoming request to. When it sees that the client browser wanted "example-app.com" it routes the request to the appropriate vhost.
Rather than having to do some fancy proxying, which certainly can be used to get to a similar result, you can just add a redirection rule that looks for requests for the host example-app.com and redirects those to example-app.com. In apache that uses mod_rewrite which people often utilize by putting rules in the ubiquitous .htacess file, but can also be done in nginx and other common web servers. The specifics are slightly different for each.
Is it possible to have the site you transfer to from a CNAME and 'A' record keep the name from the CNAME in the url? Example: Site 123.com has a CNAME called app pointing to abc.com. When I type in app.123.com, it transfers me to abc.com and keeps app.123.com in the url on the first page that I transfer to. But once I click anything on the page to move around within the page, the url reverts back to abc.com. Is it possible to have the app.123.com stay in the url while I move around. So instead of changing to abc.com/otherPage.php, it would stay app.123.com/otherPage.php?
Thanks for any help!
There are two different mechanisms at work here, DNS and HTTP.
When you use a URL containing app.123.com, that's looked up using DNS and gives the IP address that happens to be the same as the IP address configured for abc.com
But once you're viewing that page, the HTML of that page will determine how the links work, they may be absolute URLs including abc.com or they may be relative URLs, so behaviour could vary.
A site can be made to work under multiple aliases but it would need to use the request headers to detect the address used by the client and alter content accordingly.
We design and host websites for our clients/sales force. We have our own domain: http://www.firstheartland.com
Our agents fill out a series of forms on our website that are loaded into a database. The database then renders the website as a database driven website.
/repwebsites/repSite.cfm?link=&rep=rick.higgins
/repwebsites/repSite.cfm?link=&rep=troy.thompson
/repwebsites/repSite.cfm?link=&rep=david.kover
The database application reads which "rep" the site is for and the appropriate page to display from the query string. The page then outputs the content and the appropriate CSS to style the page and give it its own individual branding.
We have told the user to use Domain Name Forwarding to get the users to their spot on our server. However, everyone seems to be getting indexed under our domain instead of their own. We could in theory assign an new IP to them, the cost is not the issue.
The issue is how we would possibly accomplish this.
With all of that said, them being indexed under our domain would still be OK as long as they would actually show up high in the ranking for their search term.
For instance, an agent owns TroyLThompson.com. If I search Troy L Thompson, It does not show up in my search. Only, "troy thompson first heartland" works (they show up third)
Apart from scrapping the whole system, I don't know what to do. I'm very open to ideas.
I'm sure you can get this to work as most hosting companies will host hundreds of websites on a single server (i.e. multiple domains on one IP).
I think you need your clients to update the nameservers for their domains (i.e. DNS) to return the IP address of your hosting server. Then you need to configure your server to return the right website based on the domain that was originally requested.
That requires your "database driven website" to look in the HTTP request and check which domain was originally requested, then it can handle the request accordingly.
- If you are using Apache, see how to configure Apache to host multiple domains on one IP address.
- If you are using Microsoft IIS, maybe Host-Header Routing is what you need.
You will likely need code changes on your "database driven website" to cope with these changes.
I'm not sure that having a dedicated IP address per domain will help much, as then you have to find a way to host all those IP addresses from a single web server. However, if your web server architecture already supports a shared database and multiple servers, then that approach might work well for you, especially if you expect the load from some domains to be so heavy that you need a dedicated web server for them.
Google does not include URL in its index which return a 301 status code. The reason is pretty obvious on second thought, because the redirect tells Google "Whatever was here before has moved there, please update your references". One solution I can see is setting up Apache virtual hosts on your server for each external domain, and have each rep configure their domain's DNS A record to point to the IP address of your server.