master of my domain

July 20, 2006 6:35 PM

If I want to create sub-sites within my main site, which option is better -- and why?

Example: suppose I own http://www.domain.com

If I want to let a friend set up his own site on my domain, which of the following options would be smarter/wiser/better?

http://buddy.domain.com
http://www.domain.com/buddy

Any pointers, reasons, etc, greatly appreciated.

posted by davidmsc to computers & internet (19 comments total)

I find some people just don't understand subdomains... at all. It blows my mind, but it's something to keep in mind.
posted by phrontist at 6:37 PM on July 20, 2006

I prefer buddy.domain.com, personally. It keeps things more seperated, gives him more flexability, and it makes it easier for him to later move his site. But if you're going to do that, make sure to setup www.buddy.domain.com also.
posted by sbutler at 6:45 PM on July 20, 2006

If you want to let a friend establish his own site that will be independent--more or less--of your site, I believe a subdomain is the correct answer. It suggests a much greater degree of separation between your TLD site and his sub-site than www.you.com/him

JMO :)
posted by jckll at 6:53 PM on July 20, 2006

I'd go for http://buddy.domain.com
I'm really not sure why, but it sataisfies my MINE! MINE! MINE! MINE! itch a little more than the alternative does.

Also, the http://buddy.domain.com gives the user a separate and distinct directory structure, which can be useful.
posted by lekvar at 6:54 PM on July 20, 2006

It depends on your hosting provider, but usually a subdomain can be accessed by yoursite.com/subdomainname as well as subdomainname.yoursite.com. Subdomains just are directories under your username, so neither would be particularly safer. If I remember right, Dreamhost may not be like this, but all cPanel hosting I've seen is.
posted by ontic at 6:56 PM on July 20, 2006

If his site won't have anything, administratively, to do with yours, then you should really *encourage him to get his own domain*.

Unless hosting restrictions, and the like, make that difficult. In which case, yeah, subdomain; it's easier to move later. And can actually be on a separate server *now*.
posted by baylink at 6:58 PM on July 20, 2006

Keep in mind that 'www.' is dead.
posted by patr1ck at 7:41 PM on July 20, 2006

Typically, a subdirectory is really just a subdirectory. So if http://www.domain.com is served from
[/path/to/webroot]/httpdocs
then http://www.domain.com/buddy will be in
[/path/to/webroot]/httpdocs/buddy.
Subdomains, however, are often (contrary to ontic's statement above) served from a directory outside the standard web root, like
[/path/to/webroot]/subdomains/buddy/httpdocs.
This totally depends on how the web host has configured their system; I've seen lots of different configurations at different web hosts.

So that's a big difference. Another big thing is that, depending on your web host and how good/advanced (hopefully both) the control panel is that they give you to manage your account, you can sometimes assign specific permissions to users to that they just have ftp access to their own subdomain directory. Very convenient, when you don't want to worry about your buddy deleting your stuff.

Both approaches can be done in both ways, though, with additional trickery. Using mod_rewrite with Apache, the web server can be directed to make an arbitrary directory appear as though it's a regular subdirectory, or it can be configured to serve a subdomain from a subdirectory. Apache is a fantistically configurable piece of software, but most web hosts will only provide tools to control a small fraction of its features.

In short: subdirectories are easy; subdomains are more powerful, flexible, and complicated.
posted by dammitjim at 8:21 PM on July 20, 2006

Wow -- you guys are great -- thanks for the intel & the advice!
posted by davidmsc at 9:18 PM on July 20, 2006

www. is not dead. There are excellent DNS technical reasons relating to operations flexibility why having domain.tld be your production webserver is a Very Bad Idea; it should be only a redirect to www.domain.tld.

www is the *default* name for a webserver which has no other obvious name in your domain -- if there *is* an obvious name (forums.domain.tld, intranet.domain.tld, etc) then use that (without the www.)

If your users are too stupid to follow, then train them.
posted by baylink at 9:28 PM on July 20, 2006

If you use subdomains and need to support https (SSL) connections, you have to make sure your certificate(s) cover the subdomains.

Cookies and Javascript also behave differently across subdomain boundaries. In particular, Javascript files hosted in one subdomain can't generally access pages loaded from another. This can be useful if you want to keep your subdomains separate for security reasons, annoying if you don't.

If you later want to host the subsite on a different server, this will be a bit easier if you use subdomains.
posted by mbrubeck at 9:50 PM on July 20, 2006

In my experience, as phrontist says, users get confused by subdomains.

Even if you tell people very explicitly over and over again that the website is "http://buddy.domain.com" they will type "http://www.buddy.domain.com" into their browsers and get annoyed that it doesn't work.

So if you go with that option, make a "http://www.buddy.domain.com" as well and put in a redirect.
posted by AmbroseChapel at 9:55 PM on July 20, 2006

There are excellent DNS technical reasons relating to operations flexibility why having domain.tld be your production webserver is a Very Bad Idea; it should be only a redirect to www.domain.tld.

Would you mind elaborating on that please? What are the DNS reasons?
posted by AmbroseChapel at 9:56 PM on July 20, 2006

I'd like to second AmbroseChapel's request. I wasn't aware of any issues surrounding the common practice of dropping the "www." Now I'm all curious.
posted by lekvar at 10:36 PM on July 20, 2006

Well, there are several. You can't CNAME to the name of a domain (as opposed to the name of a host); that's the primary one. But things having to do with mail delivery in the absence of an MX record, as well as (as was noted) SSL certs, can make it painful to have a production webserver named after a domain instead of having a hostname of its own.

They're sort of obscure, and you don't always spot them until they bite you.

It can be *done*, certainly, but it binds you (no pun intended) in situations where you might prefer some more flexibility.

By all means, put a stub server there doing a redirect. But put the production server on a machine named (or CNAMEd) www.
posted by baylink at 10:42 PM on July 20, 2006

In apache it is very, very easy to configure subdomains to point to the subdirectory in question. I've always done it that way. Works fine.

I was under the impression that the only requirement for a CNAME was a valid A record to point to. MX records can exist for any FQDN:

;; QUESTION SECTION:
;google.com. IN MX

;; ANSWER SECTION:
google.com. 1448 IN MX 10 smtp1.google.com.
google.com. 1448 IN MX 10 smtp2.google.com.
google.com. 1448 IN MX 10 smtp3.google.com.
google.com. 1448 IN MX 10 smtp4.google.com.


SSL certs are nice to put on a subdomain, just to separate it out, but its not necessary. I've seen SSL certs on the 'top' domain.

Basically, the thing you have to realize is that anything past the TLD are subdomains. "google.com" is a subdomain of the "com" TLD. What separates a 'domain' from a 'host' is an A record, and, in practice, there's no reason google.com and www.google.com can't have the same A record (of course, google uses round robin DNS, so `dig google.com A`will produce a different set of IPs every time its run, but that's besides the point).
posted by devilsbrigade at 12:08 AM on July 21, 2006

Plus, in most single-server domains, the A record of every subdomain, maybe excluding smtp if your host handles that, is going to be the same, making the entire debate academic ;)
posted by devilsbrigade at 12:10 AM on July 21, 2006

If you're agnostic about which you'd prefer to implement, then the better one is the one that makes Buddy happiest.
posted by mendel at 9:10 AM on July 21, 2006

How about a DNS alias? Example: your friend has a domain name like example.com but in reality all of his files reside on your server in your "example" folder. But, unlike subdomains your friend can have his own domain.
posted by Taken Outtacontext at 10:44 AM on July 21, 2006