Is there any benefits to host our application static contents on a completely different Domain rather than host on a Sub-Domain of our main Domain like others? for exampe Microsoft uses i.microsoft.com, Google uses gstatic.com, Yahoo uses yimg.com, Stackoverflow uses sstatic.net
Thanks in advance
It should be different domain.
From Yahoo's Best Practices for Speeding Up Your Web Site
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. Yahoo! uses yimg.com, YouTube uses ytimg.com, Amazon uses images-amazon.com and so on.
Images should be on a different domain (or your CDN's domain). CSS on the other hand, can benefit from being hosted on the ROOT domain, i.e. the same domain as your web server. See this experiment that proves the better load times: http://www.jonathanklein.net/2014/02/revisiting-cookieless-domain.html
Related
Background
I'm currently using Heroku, running a single Hobby Dyno to serve both static assets and a simple API using node.js. I'm now looking to separate the static delivery and API into different dependencies. Having looked around, I'm now considering Firebase for static hosting.
Question
Using Firebase static hosting, is it possible to configure the DNS, or setup a URL rewrite, to make external API calls for a given URL, e.g.
http://myapp.com/api -> external API call to http://myapp.herokuapp.com/
http://myapp.com/* -> serve static file
If not, is it possible to configure a DNS entry to point www to Firebase, and api to Heroku?
Bonus Question
If possible; would this API call count as a cross-origin request? Preferably all requests would be made against the Firebase domain, and then everything done behind closed doors.
It is not possible to have Firebase Hosting rewrite the URL to a different server. While it is possible to have Firebase Hosting redirect the request to the Heroku server, that likely won't help you.
The common approach is indeed to split this in the DNS. Have api.myapp.com point to Heroku and www.myapp.com to Firebase Hosting.
I recently purchased a domain name from znetindia. Now I don't have any Server Host, where I can place my Static HTML file, so I placed them in public folder of Dropbox.
Because of this I wish to point my newly brought up domain name to a long file path provided by dropbox public URL like:
http://dl.dropbox.com/u/2025503/servers/Experimental%20projects/letstartup.net/index.html
And I have following options in my domain name page from where I brought it:
DNS will only allow you to specify a different hostname or IP address for your domain name; you cannot use DNS to specify a different URL. (DNS is used for lookups for smtp, imap, ftp, sftp, ssh, telnet, imap, sip, dns, dhcp, irc, xmpp, nfs, cifs, etc. -- far more than just web browsing.)
Many registrars / hosting providers will run a web server on a host for you that can immediately issue an HTTP 301 response to an URL of your choosing. My registrar, Gandi, has placed these controls under a "web forwarding" heading. They will run a webserver that will respond to all requests for your domain with an appropriate HTTP redirect code to an URL of your choice.
I do not know if ZNetIndia provides a "web forwarding" option -- certainly none is visible in the screenshot you included, but that isn't a surprise, because managing DNS is different than managing web forwarding requests. If they don't provide web forwarding as an option, then you can certainly get a super-cheap webhost that can either perform redirects as you wish, or provide you directly with hosting.
our hosting account is set up with the domain www.nashman.ca, and our application is at www.nashman.ca/hub. We have another domain that forwards to www.nashman.ca/hub and that's hub.mhn.co. The problem i'm having with this is that the forwarded domain adds on the /hub whenever you navigate to another page from hub.mhn.co, so the domain shows as hub.mhn.co/hub/admin when you're in the admin area, for example. I need the domain to stay consistent, and never show that folder name, because its breaking some of the javascript I use. What is the best way to set this up?
edit
I've been doing some reading about URL Rewriting, and looking into it - my hosting provider supports the IIS7 URL Rewrite module. All the tutorials I've found so far detail how to set up rules using the IIS config tools, but I don't have access to them. Is there a way to do it by editing my web.config in my apps root directory? And will this solve my issue?
Is the default page for hub.mhn.co using a redirect to www.nashman.ca? If so, what is happening is that the forwarding software basically returns a new URI that the browser requests, and the new URI will replace the old one in the browser window and thus in all future requests. You're probably redirecting to ~/hub/ (the hub subdirectory of the site root) which will result in the browser requesting a new URI that keeps the domain name but tacks on the subdirectory.
If you have direct control over the DNS and your webservers, you can use the DNS configuration to direct a request for the hub.mhn.co domain directly to the /hub subdirectory of your webserver. That way, the browser never knows that hub.mhn.co is actually www.nashman.ca/hub/. You might have to direct to an alternate port on the webserver and map that port to the subdirectory, depending on your DNS software (IIRC, most can deal with ipaddress/subdir routes, but some can only handle routing to ipaddress:port).
If your IT department does not have direct control/ownership over your DNS routing, or your exact hosting environment, you are more or less at the mercy of your hosting provider. They may be able to set up their environment to do the same thing, or not; all you can do is ask.
EDIT: Basically you have two options left if you're hosting remotely and can't use their DNS to reroute silently.
First option: clone (copy all files from) the web layer of nashman.ca/hub as hub.mhn.co under a different root space in your hosting environment (try to keep any hooks to service-layer code over at nashman so you don't have to copy the whole vertical slice). If you must also keep the UI under the /hub/ subdirectory, you're repeating code, but you may be able to mitigate this with deploy scripts that will allow you to deploy one local copy of your codebase to various locations. This may also cost more as your hosting environment is now hosting two non-trivial sites.
Second option: host the site and/or resolve the calls on your own hardware. As long as you have a public, static IP address through your ISP, you can provide a DNS server that will be the "authoritative" server for nashman.ca and hub.mhn.co domains. Your ISP or a third party domain name registry can provide a "pass-down" route to get requests from the TLD servers down to you. Then, you can route requests to whatever IP address, port and/or subfolder you like; that can be a remote webhosting provider (as long as they don't mind JUST hosting your site) or your own webservers. This will require the hardware, and a static IP from your ISP. If you lose power to this server, your site will be unreachable until power's restored. If the IP address of your DNS server changes, your site will be unaccessible by DNS until the server that routes requests to you updates its routing table with the new IP (which can be up to 24 hours).
I want to create a blog for an e-commerce website, but due to data security reasons I don't want to host the blog on the same machine as the website is hosted on. Is there a way to
host it on a separate machine using the sub-domain of blog.domain.com but have it be accessible via the url www.domain.com/blog.
My reasoning is that the content will help with seo better if it uses the same domain.
I was thinking about using mod_rewrite but I'm not sure if it would allow page retrieval from a different website.
It is possible to use the Apache module mod_proxy to make the contents of a server appear to be hosted on another server, and therefore appear to be hosted under a different domain. You might like to take a read of this page which details the Apache configuration directives needed to get it up and running. If that doesn't offer enough options for setting it up how you want it, then you could investigate the "force proxy" option in mod_rewrite, which allows you to send certain rewritten requests through mod_proxy to do the proxying.
I have a Default Web Site and another web application (let's call it Application2) inside the Default Web Site in IIS7.
I have 2 registered domain names, let's say www.example.com and www.example.net.
I would like to configure things that when I open www.example.com I get Default Web Site, when I open www.example.net I get Default Web Site/Application2.
www.example.com -> Default Web Site
www.example.net -> Default Web Site/Application2
How can I do that?
First you need to decide if your going to use Name Based or IP Based hosting.
IP-Based uses unique ip's to determine which virtual host it will serve and Name Based will actually use the host header which is sent by your client browser.
So let's see two scenarios:
Scenario # 1 (ONE IP TO SHARE)
You have a server with only one IP, could be either private or public as long as the domains you are serving are properly configured in the dns serving you internally or your client externally (NAT).
I suggest that for the sake of this tutorial you stop the default website. Ok.
You will set up one site in II7 and name it accordingly. Go to the right hand side of the manager and look for "Bindings" under actions menu; making sure you have the new site selected on your left pane. Now under "Site Bindings" select the ip address you will be sharing between the sites (name based hosting). Under "Hostname" enter domain # 1 "www.example.com", hit ok.
Follow the same procedure above with the other domain or domains, making sure they have diferent hostnames and same ip's.
That's it. You will now be able to start those sites and run them at the same time.
The same principle above applies if your using the "Default Site". "Default Site" is just a name MS gave the default created one.
Scenario # 2 (MULTIPLE IP TO SHARE)
If you have either some private or public ip to spare, or at least until you do the exercise the only diference here is that sites you will set up and don't have to specify the "Hostname" per each site, as this is basically done in the DNS zones itself. The sites will respond for any request made to those ip's on port 80 regardless.
When will you need to use multiple Ip's to serve websites. Well it all depends.
Some reasons are: Network Isolation (Security), Applications which don't work well under name based hosting, SSL Certificates Bindings 443(PRE II7), and mostly complete control over site. There are of course more reasons, but I'll let others write a bit also.
Have fun.
Edit... upon further investigation I found that if you can set up multiple sites and run them simultaneously. Just need to stop and start the sites after setting the host values to get them to both run at the same time.
Original post:
The straight-forward way to do this would be to add another application by opening IIS and right-clicking Sites then select Add Web Site. In there you can specify the physical path of Application2 and also set the "host" to "www.example.net" which will filter all those requests to your second site. Any requests that don't match "www.example.net" will still go to the default web site.
That approach will work fine on Windows Server using IIS, but on Vista's IIS7 it won't work since you can only have one site running at a time. To start the second site, you'd first have to stop Default Web Site.