I have an interesting issue with HTTPS ports not being handled properly. It is a relatively small issue and I bet it is pretty simple to solve, I am just not thinking of it.
We have a website served with IIS 6, www.mylongdomainname.com. We have a secure portal which is handled via https://www.mylongdomainname.com. Now we have several vanity and marketing URLs that we use over the phone like www.shortname.com, etc. I have two websites setup, one that handles all request with the header www.mylongdomain.com which actually serves the website. The other accepts any traffic and permanently redirects to www.mylongdomain.com. This way if we ever add any more domains, they will all end up at the one, also it redirect mylongdomain.com to www.mylongdomain.com.
Everything here works fine. The issue now is when I google "shortname.com," the first result returned is the same as if I were googling "mylongdomain" however, google has been able to crawl the other pages via https://shortname.com and index them that way. We dont have SSL certificates for these other domains, so when you click through, you get a nasty un-trusted error.
This really wouldn't be an issue if we didn't use these URLs over the phone, and you all know how many people don't know the difference between the URL bar and a search box.
any suggestions or tips?
I'd set up a redirect so that https://shortname.com is sent to http://shortname.com with a 301 (permanent) redirect. This will put an end to the nasty untrusted error immediately. Furthermore, this will also cause Google to slowly but surely update their index.
There are multiple ways to do this. If you're using IIS7 you can use the URL Rewrite Module and write a redirect rule to take care of it.
Or if you're not on IIS7 it may be perfectly acceptable to write some code to accomplish this. I wrote some ASP.NET I've used plenty of times to take care of this HTTP/HTTPS redirection. In your particular case you could simply take my code and call SetSSL(False) in the Application_BeginRequest function of your global.asax.
Related
I have around 15+ sites, and we want to drop these sites and merge them into only one site (create pages for each one in the new site).
The 15+ site's domains should be redirected to one site as below:
a.com -> z.com/a
b.com -> z.com/b
c.com -> z.com/c
..
Also, we want to redirect (301) page by page from the old domains to the new the new domain to keep the page's ranking:
a.com/about-us -> z.com/a/about-us
b.com/about/abouus -> z.com/b/about-s
c.com/contactus -> z.com/c/contact-us
Each one of the 15+ sites is running on its own server with a different platform while the new server is IIS.
Currently, I'm thinking of two approaches:
Point the old DNS records to the new server of z.com, and handle all the redirects on the server.
Keep the old site running, and configure redirect rules on each server to redirect each page to the matching page on the new site.
Which approach is better, any other approaches? So far I think the first approach is better since we will control all the redirects in one place - but from the performance wise, is it going to add more headache on the server?
The Scenario
You created a new site and you want to redirect all old sites(15+) to new site (page to page).
All old sites are running in it's own server on different platforms whereas the new one is IIS.
Your options
Point the old DNS records to the new server of z.com, and handle all the redirects on the server.
Advantage
Less cost - you can remove all old sites and the server cost can be saved.
Internal redirection. So, time will be less
Disadvantage
Complex to perform
take care of conflict of similar pages(double check the redirection path)
Keep the old site running, and configure redirect rules on each server to redirect each page to the matching page on the new site
If you can afford the cost of running 15 different sites on 15 servers just to redirect, then only go for this method.
It is just a waste of money and the redirection time will be more.
I think eventually you'll have to shutdown all the other sites as in the long term unlikely does it make sense to keep 15 sites running just to do the redirects.
So as I understand the question is rather on how to better organize the migration to the new system in the short term. So here are my thoughts on this:
how huge is your system
what's your QPS?
how many pages do you have across your sites farm?
do you need to remap URLS for a decent amount of pages?
what's the migration procedure? Will you switch your sites one-by-one or it's technically infeasible and they all need to be swtiched over at once?
If we're talking about a system handling 10 QPS and 1K pages or about a system handling
50K QPS and having 1B pages we need to dynamically remap system load may be a concern and p.2 may look better
rollbacks
note that DNS records can be cached by intermediate servers and if you need to quickly rollback to the previous version if something goes wrong it can be an issue
what kind of systems do you have
Is it actually possible to easily extract URLs from 15 diverse systems and put them to a single point without a risk to lose something valuable?
ease of maintenance
At first glance the first approach looks easier from the maintenance perspective, but I don't know what kind of system you use and how complex the redirection rules need to be.
If they are complex dynamic ones like a.com/product.php?id=1 => z.com/a/iPhone6S moving millions of such urls to a single point could be tricky
SEO
I don't follow the industry closely, but a few years ago both would work ok. I think it's worth consulting those keeping up to date with this industry - it changes very rapidly
Your first approach is definitely the best.
It is easy to maintain
You needn't to keep old infrastructure (though in your second case you'll need to keep only redirecting frontend like apache, nginx or lighthttpd)
There are no performance risks as from one visitor request to old location, redirect answer and than request to new location will come in turn and not simultaneously.
DNS records are not capable of HTTP redirection which is crucial for SEO. To make sure your redirect is 301 HTTP redirect you can use sniffer.
The answer is just make sure your redirect is 301 HTTP redirect so you get your SEO right. Other than that it's just a matter of taste / architecture / money rather than standards.
UPDATE
Read more:
wikipedia
Both Bing and Google recommend using a 301 redirect to change the URL of a page as it is shown in search engine results.
ehow.com
A 301 redirect is a search-engine friendly way to move a domain. The 301-redirected domain does not cause duplicate content in the search engines so that you do not harm your search engine rank. Using a new DNS setting is required to have a new domain name, but it does not redirect browsers or search engines. Both of these methods are used to move to a new domain.
webmasters.stackexchange.com
Duplicate content occurs when the same content is available on two different URLs. To prevent duplicate content on www vs no-www, use 301 redirects to redirect one to the other. To implement redirects, it is the webserver that needs to be configured properly. As long as DNS is pointing to the webserver (either CNAME or A record), then the webserver can be configured properly.
I was stuck with this problem some months back. I wanted to redirect a whole site into a new site's structure. The old site was .php which I know nothing about.
I figured I'd point the old website's DNS at my server and write some MVC code to catch every request, and then use a set of rules using the vb.net Like operator to compare the inbound Url with my ruleset.
It worked a treat. I redirect 300+ pages to my new site with about 10 rules. These include changes of folder structure, a forum (which was mainly junk but had a few good questions), and I implement a "catchall" rule which points to the new home page, in case I missed something.
It worked so well I've packaged it up as a commercial product and it publically available. It is free with link from the destination site (in your case just the single destination site).
https://301redirect.website/
There are a couple of demo videos on the homepage which will explain the setup in a few minutes.
We're seeing some minor issues with a cache and https on a non-secure site/domain.
The site doesn't have a certificate and therefore is not https. URLs are generated dynamically on the site though, so if someone manually visits the site using https, https will be used in the relative URLs - this is an issue for images and external resources as they then get blocked.
On an individual basis this doesn't worry me, the real issue is that if the above happens on a page that hasn't yet been cached, the cache reflects the https error in the URLs, and attempts to serve https resources to normal users, thereby leaving all external resources blocked. We've just seen this happen on a set of pages.
I have no idea why someone would be attempting to access the site using https, but unfortunately it seems to happen.
Is there any way to route all https traffic directly to http? It's a frustrating issue as the site doesn't purport to be secure, doesn't have a certificate, and therefore security issues like this are meaningless - ideally https requests should just be being parsed as http.
Any help appreciated!
Edit:
Turns out after some research that this may not be possible. The method suggested in the comments should work (with the addition of an on/off flag for the condition), however it only works if SSL is available. i.e. if https isn't working in the first place, it doesn't seem you can build conditions around it.
I recently bought SSL for my website and want to create a section within the site in the form of https://secure.example.com/member/upgrade.aspx. However, I am having a hard time solving this issue since currently my website URL rewrite prohibits any subdomain and the user is logged out if he or she gets transferred to the above link.
I have search online and found some good information such as dynamically create the url without actually creating a subdomain in IIS.
Questions:
What steps are needed to achieve the objective above?
Should I have bought the wildcard certificate instead of one for a specific subdomain?
Thank you.
One option would be ignoring that url pattern for rewrite purposes or ignoring the url if the protocol is HTTPS. That said, I would take a slightly different approach here and just put the entire site behind SSL -- rewriting all the queries to the other protocol works and google is now giving rankings bumps to HTTPS so there are good business reasons to make the switch. You are already taking the pain of getting SSL involved at all -- the dedicated IP and certficate cost the same if you use them on a single page or all the pages, might as well take advantage of it and ease your management burden in the same motion.
There has been a question made towards me recently to do the following:
We have a website with Drupal running in IIS.
On that site is an URL Redirect to a website hosted externally, obviously with a name completely irrelevant to the name of our company.
The question now is the following;
They want to change to URL to a subdomain of our website. Example: from "www.external-site.com" to "www.sub.internal.com" (while still showing content of the external website)
They want the current page of that website to be reflected in the URL bar. So it wouldn't say "www.sub.internal.com", but it would say "www.sub.internal.com/solutions/page1.html" (instead of "www.external-site.com/solutions/page1.html")
It's possible that I forgot another 'condition' but have mentioned before this.
So, if someone visits through our URL Redirect to External-website, it needs to show our subdomain instead of their domain in the URL, AND it needs to show the current page when people start browsing while still using our subdomain in the URL.
Now, I checked the external-website, and it seems that most of the links available are relative links (if this would be any useful information).
Currently, the external website is hosted externally, and will remain to be so for next few years. (I believe we bought the company)
I have been asking around and looking up, and the best possible thing seems to use domain forwarding, but even then it still doesn't seem to comply with the entirety that they asked of me.
I am but a 'simple' .NET programmer, held responsible to do support for anything involving the websites, and I can't say I have extended knowledge about infrastructure. (But I can ask people to do this for me)
Is there anything that could solve this?
Thanks so much!
IIS's URL rewite and Application Request Routing (ARR) combo can help you what you want to achive. Here are few links which may guide you to configure ARR. Please note that these links dont exibit exact solution to your problem however you can take clue from it and fabricate your solution accordingly.
http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing
http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-rule-template
It sounds like you'll want to use a full-page iframe: do not redirect but show a page with an "inner page" instead: that inner page is the external web site. That way, users do not see the external site in their URL bar.
http://webdesign.about.com/od/iframes/a/aaiframe.htm
You need to configure the equivalent of Apache Virtual Host with Reverse Proxy on IIS.
See this answers:
https://serverfault.com/a/271030
and
https://stackoverflow.com/a/10003306/2131693
I'd like to know how websites have created URLs with other domains like these on trafficestimate.com.
I'm guessing it's some .htaccess stuff to redirect domain names to a dynamic page?
Thanks
Your URL has an GET Request. So when someone calls the page http://google.com/search with the parameters hl=en, safe=off etc., the page can process those parameters. So for instance safe=off means that you want to get back any search result. The q=site:... is your search string. In this case Google will look it up in its database and give you the results. So when you call this URL there is probably no .htaccess processing done. However you can process the URL and GET request with .htacces and i.e. redirect the user to another page.
Maybe you'll describe a bit further what exactly you trying to do/want to know. This makes explaining easier.
EDIT: After reading Gumbo's comment I looked at the Google result page. So maybe your question means the trafficestimate-URLs. They look like http://trafficestimate.com/example.org. This is really a good case for .htaccess. So using .htaccess they take the URL and redirect it to http://www.trafficestimate.com/websites/?domain=example.org. Here you have again a GET request and an application builds the page.
Some URL rewriting is probably involved. Otherwise they would have to create an existing file for every possible request.
Using Apache’s mod_rewrite in a .htaccess file is one option. But since the server identifies itself with “Microsoft-IIS/7.5”, they are probably rather using ISAPI_Rewrite, a mod_rewrite derivative for Microsoft’s IIS.