How do they differ in terms of backend/frontend architecture and implementation?
I know how to use domain.com/xyz where the page is rendered on the basis of information of xyz, how would that be done with xyz.domain.com
For example tumblr urls are like username.tumblr.com. How do they differ from, say, facebook pages where urls are like facebook.com/username?
Domains
Domains are an autonomous administrative structure. Assets within the same organization can be compiled into a domain. Public facing domains (somehow, be it direct or through security measures) connect to the internet. They don't even need a web server.
tumblr .com
------ ----
2nd level TLD - Top level domain
domain
Anything after (to the left of) tumblr is what is called a sub-domain or lower level domain. Sub-domains represent a smaller autonomous administrative organization within the main domain, i.e. Microsoft has a HR department so hr.microsoft.company would be synonymous to this situation.
Paths
username in facebook.com/username represents a path to a resource on the domain facebook.com, most likely (duh) on their webserver at port 80. I realize this is an oversimplification since Facebook probably uses a complex structure to deliver their content, but nevertheless, I'm hitting in the general area.
Going along with the HR analogy, they may maintain a series of forms for employees to access. Those would be stored as a resource rather than their own separate administrative structure.
hr.microsoft.company/forms/i9_tax.form
The Difference
The difference between a path and a subdomain is that a path represents a resource on its domain's webserver, while a subdomain is content, either from the same web server or a different one from the 2nd level domain, but with it's own DNS record. A subdomain on the same web server as the 2nd level domain would be a "CNAME" (canonical name) record within the DNS database, while a completely difference web server would be an "A" (hostname/alias) record.
So domain.com/index.html points to the index.html file within domain.com's public html directory where as xyz.domain.com points to either the hostname of a completely different web server or to a directory within domain.com's file structure like domain.com/useassubdomain/xyz, but (again) with it's own DNS record. Both can be configured like any ole' webpage (as long as the servers running them support it).
A few reasons you would choose to utilize a subdomain over a resource of the original domain's subdirectories is because you want to:
Distinguish regions or language (ja.wikipedia.org)
Distinguish a branch with different goals than the larger organization (windowsupdate.microsoft.com)
Sub-brands
Delegate ownership or administration of content (including custom content like tumblr)
Related
Why do some websites I see have a URL in the form a.b.example, and others are in the form of b.example/a?
For example, why is it gist.github.com instead of github.com/gist?
These are different components. See section 3 of the URI standard for a list of components and their definitions.
https://gist.github.com/
The authority (or more specifically, the host) is gist.github.com.
The path is /.
https://github.com/gist
The authority (or more specifically, the host) is github.com.
The path is /gist.
As https://gist.github.com/ would typically also have paths like the second URI (e.g., https://gist.github.com/foobar), I guess you are primarily interested in the authority component.
In your examples, the DNS gets used, i.e., these are domains, which consist of labels, separated by .:
gist is a third-level domain (aka. subdomain)
github is a second-level domain
com is a top-level domain (TLD)
The top level controls the second level, the second level controls the third level, and so on. So if you buy the domain name github.com, you typically have control about all of its third-level domains (and fourth-level, etc.).
It’s up to the webmaster which kind of URI design gets used, and the decision can depend on many different factors: what is technically possible for them and the systems they use, usability (example), SEO (example), etc. A common reason for using different host names (domains) is that they can be easily hosted on different servers.
Examples:
eBay uses different (top-level) domains for each of their localized sites (e.g., http://www.ebay.de/ for Germany, http://www.ebay.it/ for Italy)
Tumblr uses a subdomain for each of their users (e.g., http://alice.tumblr.com/ for Alice, http://bob.tumblr.com/ for Bob)
Twitter uses a path segment for each of their users (e.g., https://twitter.com/alice for Alice, https://twitter.com/bob for Bob)
Wikipedia uses subdomains for different languages (e.g., https://en.wikipedia.org/ for English, https://fr.wikipedia.org/ for French)
In terms of s3 urls, are there really 2 kinds? And why? What are the different syntaxes?
bucket.s3.amazonaws.com/key
and
s3.amazonaws.com/bucket/key
Is this it? Why are there 2? Are there more? Are these correct?
AWS is deprecating old path style URLs:
https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/
Old vs. New S3 currently supports two different addressing models:
path-style and virtual-hosted style. Let’s take a quick look at each
one. The path-style model looks like either this (the global S3
endpoint):
https://s3.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg
https://s3.amazonaws.com/jeffbarr-public/classic_amazon_door_desk.png
Or this (one of the regional S3 endpoints):
https://s3-us-east-2.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg
https://s3-us-east-2.amazonaws.com/jeffbarr-public/classic_amazon_door_desk.png
In this example, jbarr-public and jeffbarr-public are bucket names;
/images/ritchie_and_thompson_pdp11.jpeg and
/classic_amazon_door_desk.png are object keys.
Even though the objects are owned by distinct AWS accounts and are in
different S3 buckets (and possibly in distinct AWS regions), both of
them are in the DNS subdomain s3.amazonaws.com. Hold that thought
while we look at the equivalent virtual-hosted style references
(although you might think of these as “new,” they have been around
since at least 2010):
https://jbarr-public.s3.amazonaws.com/images/ritchie_and_thompson_pdp11.jpeg
https://jeffbarr-public.s3.amazonaws.com/classic_amazon_door_desk.png
These URLs reference the same objects, but the objects are now in
distinct DNS subdomains (jbarr-public.s3.amazonaws.com and
jeffbarr-public.s3.amazonaws.com, respectively). The difference is
subtle, but very important. When you use a URL to reference an object,
DNS resolution is used to map the subdomain name to an IP address.
With the path-style model, the subdomain is always s3.amazonaws.com or
one of the regional endpoints; with the virtual-hosted style, the
subdomain is specific to the bucket. This additional degree of
endpoint specificity is the key that opens the door to many important
improvements to S3.
The additional functionality of providing multiple URL patterns for an object in the S3 is due to the Virtual Hosts and Website Hosting and publishing the data from the root directory. I got this info from
In the Bucket starting URL style - bucket.s3.amazonaws.com/key you can simple add the files like favicon, robots.txt etc where as in the other URL pattern - s3.amazonaws.com/bucket/key - there is no notion of root directory where you can put those files.
Content Snippet from AWS S3 Page - Virtual Hosting of Buckets :
In general, virtual hosting is the practice of serving multiple web
sites from a single web server. One way to differentiate sites is by
using the apparent host name of the request instead of just the path
name part of the URI. An ordinary Amazon S3 REST request specifies a
bucket by using the first slash-delimited component of the Request-URI
path. Alternatively, you can use Amazon S3 virtual hosting to address
a bucket in a REST API call by using the HTTP Host header. In
practice, Amazon S3 interprets Host as meaning that most buckets are
automatically accessible (for limited types of requests) at
http://bucketname.s3.amazonaws.com. Furthermore, by naming your bucket
after your registered domain name and by making that name a DNS alias
for Amazon S3, you can completely customize the URL of your Amazon S3
resources, for example, http://my.bucketname.com/.
Besides the attractiveness of customized URLs, a second benefit of
virtual hosting is the ability to publish to the "root directory" of
your bucket's virtual server. This ability can be important because
many existing applications search for files in this standard location.
For example, favicon.ico, robots.txt, crossdomain.xml are all expected
to be found at the root.
I have a Ruby on Rails application where my customers should ask their customers to go. But I would like to be able to hide/mask my own domain name from the url, so the customers of my customers don't feel like they are on a 3rd party website.
For example, if my domain name is:
https://app.example.com/visit/:customer_id
then what is my options for masking the example.com part?
If it is not possible to mask the domain name (I can see that even by using the IP address directly, https errors appear), then is it possible to put in some prefixes like e.g.:
https://prefix.app.example.com/visit/:customer_id
https://app.prefix.example.com/visit/:customer_id
https://app.example.prefix.com/visit/:customer_id
Btw, it's not important to keep the https security on these pages particularly, but I don't suppose it is possible to have an application that has both encrypted and non-encrypted pages?
your customers will have to setup their DNS to point to your application. you can use a CNAME to accomplish that. this can be done by using a subdomain.
if you use SSL/HTTPS you have to make sure that the certificates match the domain.
like #lassej already pointed out, an iframe is probably a better way of integration. it has several limitations though.
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.
I'm looking at using ASP.NET for a new SaaS service, but for the love of me I can't seem to figure out how to do account lookups based on subdomains like most SaaS applications (e.g. 37Signals) do.
For example, if I offer yourname.mysite.com, then how would I use ASP.NET (MVC specifically) to extract the subdomain so I can load the right template (displaying your company's name and the like)? Can it be done with regular routing?
This seems to be a common thing in SaaS so there has to be an easy way to do it in ASP.NET; I know there are plugins that do it for other frameworks like Ruby on Rails.
This works for me:
//--------------------------------------------------------------------------------------------------------------------------
public string GetSubDomain()
{
string SubDomain = "";
if (Request.Url.HostNameType == UriHostNameType.Dns)
SubDomain = Regex.Replace(Request.Url.Host, "((.*)(\\..*){2})|(.*)", "$2");
if (SubDomain.Length == 0)
SubDomain = "www";
return SubDomain;
}
I'm assuming that you would like to handle multiple accounts within the same web application rather than building separate sites using the tools in IIS. In our work, we started out creating a new web site for each subdomain but have found that this approach doesn't scale well - especially when you release an update and then have to modify dozens of sites! Thus, I do recommend this approach rather than the server-oriented techniques suggested above based on several years worth of experience doing exactly what you propose.
The code above just makes sure that this is a fully formed URL (rather, say, than an IP address) and returns the subdomain. It has worked well for us in a fairly high-volume environment.
You should be able to pick this up from the ServerVariables collection, but first you need to configure IIS and DNS to work correctly. So you know 37Signals probably use Apache or another open source, unix web server. On Apache this is referred to as VirtualHosting.
To do this with IIS you would need to create a new DNS entry (create a CNAME yourname.mysite.com to application.mysite.com) for each domain that points to your application in IIS (application.mysite.com).
You then create a host header entry in the IIS application (application.mysite.com) that will accept the header yourname.mysite.com. Users will actually hit application.mysite,com but the address is the custom subdomain. You then access the ServerVariables collection to get the value to decide on how to customize the site.
Note: there are several alternative implementations you could follow depending on requirements.
Handle the host header processing at a hardware load balancer (more likely 37Signals do this, than rely on the web server), and create a custom HTTP header to pass to the web application.
Create a new web application and host header for each individual application. This is probably an inefficient implementation for a large number of users, but could offer better isolation and security for some people.
You need to configure your DNS to support wildcard subdomains. It can be done by adding an A record pointing to your IP address, like this:
* A 1.2.3.4
Once its done, whatever you type before your domain will be sent to your root domain, where you can get by splitting the HTTP_HOST server variable, like the user buggs said above:
string user = HttpContext.Request.ServerVariables["HTTP_HOST"].Split(".")
//use the user variable to query the database for specific data
PS. If you are using a shared hosting you're probably going to have to by a Unique IP addon from them, since it's mandatory for the wildcard domains to work. If you're using a dedicated hosting you already have your own IP.
The way I have done it is with HttpContext.Request.ServerVariables["HTTP_HOST"].Split(".").
Let me know if you need more help.