Hacker News Reader

Comment by beagle3 | Hacker News Reader

What is the use case that requires http://test.10.0.0.3.xip.io/test-page rather than http://10.0.0.3/test-page ? I've been using the latter on iphones and ipads with no problem.

Honest question.

View on HN

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

"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.

This would support multiple vhosts.

Multiple sites of course, though that can be solved with ports.

Some things are harder to do without a hostname - cookies, for instance, can be tricky.

I have dealt with weird edge cases in frameworks/proxies/whatever where sometimes the hostname turned into an IP (or 10.0.0.3 turned into 127.0.0.1). You generally don't want this to happen in production, and performing all your testing with names is a good way to observe it not happening.

I could see how it'd help if you are debugging a service that parses a subdomain out of the main URL for a particular purpose (think, for example, a SaS that provides a domain like 'yourcompany.mysasservice.com').

Other than that, ports will do.

Reply on news.ycombinator.com