"You can't test multiple sites on the same host using just the IP."

I'm not getting what the problem is. Isn't this what ports are for? Or even just running the websites on different folders?

Sometimes vhosts are convenient, sometimes they're even mandatory. For example, with XMPP servers, multi-user chat and any components must live on a subdomain. So if your main server is running on example.com then the MUC server is, say, conference.example.com and component "foo" is foo.example.com. No way around it short of hacking the source (and, if I'm not mistaken, violating standards.)

This is just one situation where I can see this come in really handy during development.

> For example, with XMPP servers, multi-user chat and any components must live on a subdomain.

This is only necessary if you want users outside your domain to access your component. While you probably want to do so for MUC, you might not necessarily want to bother for your user directory or gateways. I've run many servers over the years and long since stopped creating a host/subdomain for each component.

Interesting, this must be a shortcoming of OpenFire then. With OpenFire I haven't found a way around having the MUC and extension subdomains accessible via DNS, regardless of whether or not requests are coming from the same domain or not. Is this not necessary with other XMPP servers? Which ones are you using, if I may ask?

It is indeed a shortcoming of OpenFire; one that won't be fixed [1].

As far as the XMPP protocol is concerned, the concept of sub-domains doesn't matter. It's useful for human users when configuring servers though.

Prosody for example allows running a multi-user chat service on example.com. And there's an undocumented feature which let's you have user@example.com be a user, and room@example.com be a chatroom.

[1] http://issues.igniterealtime.org/browse/OF-162

I've used jabberd2 and ejabberd, neither of which had that constraint. Can't remember from my experiments with OpenFire or Prosody.

Not a problem with ejabberd.

Depends on what it is you're testing. You could be testing a vhost setup, in which case different ports or paths wouldn't suffice for testing. More specifically you could be an application's behavior when given different vhosts. Make sense?

This is the best way to get a "natural" development environment (i.e. as close to production as possible). Also, it's a pain in the ass having to start and stop various apps and remember ports, which is what Pow is great for in the first place.

Ports are a pain in the ass compared to persistent names.

Which is when you add them to /etc/hosts

Can't do that on an iPhone or iPad

Actually you can test two at a time by using an alias in /etc/hosts.

In /etc/hosts:

1.2.3.4 site1.com site2.com

Then you have to edit /etc/hosts to try two more sites.

The idea that the user cannot access /etc/hosts on the iPhone is reason enough to jailbreak it. Denying access to /etc/hosts means the iPhone cannot connect to the any website that requires a hostname, even when the iPhone can connect to the internet, unless the iPhone can access some DNS server (which of course Apple probably wants to control). That is a ridiculous limitation. The internet nor the web requires DNS to work, but the iPhone requires DNS to access the web.[1]

1. assuming the website is using virtual hosts or otherwise requires a hostname

Well this service helps a lot, not only where access to /etc/hosts is restricted but also for other devices, just for convenience.