Enterprise internal URL conventions

Question

developer here... I'd like your IT perspective on this one...

I'm building a new internal web app for my company, and starting to think about how it will be deployed. Many of the existing web apps here are linked-to using their server names directly, like this:

http://webserver123/someInternalApp/

This makes me uncomfortable for a variety of reasons. Server names change, servers go down, and users shouldn't have to know server names to find their web application. Using server names prevents us from swapping servers or adding load balancers. If you can think of other reasons this is bad, let me know so I can make a better case for changing this practice.

Going forward, I'd like to have some better domain names set up in our internal DNS that will point back to the appropriate web server & app. In my last job, we followed a convention something like this:

• For Production: http://someInternalApp.myCompany.com/
• For Test: http://test.someInternalApp.myCompany.com/
• For Development: http://dev.someInternalApp.myCompany.com/

I like this better, as the application name is a key part of the domain name, and the dev/test/prod environment designation is simple. However, I have some reservations:

• Putting the app name in the subdomain will eventually create a lot of long, unique subdomains. I like having different domains for each app, but I also feel it could get difficult to manage.
• Other than the app name, there is nothing to designate that this URL is internal only. I've read about other organizations using a subdomain like "corp.myCompany.com" or "int.myCompany.com" which could be good. I don't want users to get the impression they can access these from home.

Here are some options on what I'm leaning toward for internal domain names:

App name in the internal subdomain: (they get a bit long, but everything is packaged together well I think)

• http://someInternalApp.corp.myCompany.com/
• http://dev.someInternalApp.corp.myCompany.com/

App name as a subdirectory: (shorter domain name, but it implies all the apps are part of one unified site, which they may not be, and it disconnects the environment designation from the app)

• http://corp.myCompany.com/someInternalApp
• http://dev.corp.myCompany.com/someInternalApp

So, let's discuss... What do think about these options? Is there something better or more common I may have missed? I have the opportunity to set my company on a better path in this regard, so I'd like to find a good convention to recommend.

Thanks!

Answer 1

Never rely on whether your app will be internal or external. Always develop as though the audience of the app will be outside your control (because it is).

Go with ENV.APPNAME.DOMAIN.TLD

With www. as the alias for "production".

Answer 2

If you are deploying internal only, you have great freedom in selection. However with the Top Level Domains opening up as they have recently, you do want to take some care to not conflict with an upcoming new external name.

eg, you could deploy as http://contact.app/ but if the .app TLD gets registered then you could find yourself conflicting.

So you are probably best using something like http://contact.local/ or http://contact.lan/

For reasons of Apple and their Bonjour service compatibility you are best to avoid .local so perhaps go with .lan

Alternatively just http://contact.ourcompany/ would work pretty good if your company name is highly unlikely to ever become a TLD.

I would avoid the app name as a subdirectory because it is unnecessary and just makes it longer. Virtual hosting is the way to go there with a unique URL per app.

And you are quite correct in avoiding server names, that is a definite no-no because servers come and go.

Edit 1: See RFC2606 and take your pick from the available internal use TLD's referenced there.

Just as a note to the comments - .local and .lan as I recommend are not registerable as per the above RFC. You could use .priv and .test as well for the same reasons.

Answer 3

This somehwat opinion based because when you only deploy your application internally you have full control and than it really doesn't matter what you do...

Most users will bookmark what internal web applications they need to use anyway, so don't fret too much about their URL's.

As the sysadmin I would love more applications that give me the choice to deploy either in a configurable subdirectory or the root on a subdomain, allowing the choice of using subdomains or not.

It takes a more considerate developer not to go the "easy" route and just include a hardcoded (relative) reference "href=/images/bullet.png" on a random page and instead of building a reference from a number of deployment/configuration settings "href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Please make your deployment choices such as any hostnames, port numbers, choices in HTTP/HTTPS configuration settings and do not hardcode them.

I have often been on the receiving end "management wants all internal apps under http://intranet/apps/ because appname.intranet is soo confusing. And the opposite from our vendors; we need appname.intranet for our appliance/application as we have built-in check against iframes, inlining man-in-the-middle-attacks and reverse proxying....

I've found that a lot of commercial web applications expect to be deployed in the root of the webserver and don't work too reliably when deployed in some random subdirectory. I.e. they include, for instance, more or less hard-coded paths to /css/main.css sub-directories, making it difficult to host multiple applications on the same host. But those lot do not appear overly worried about the portability of their code either.