WhatsOnWhen services use what are commonly referred to as Virtual Server configurations in order to provide hosted services and feeds. Our core application uses information contained in the request to decide which customer's content is being requested and to display the correct page (or provide the assoicated feed).

We do this by processing the HTTP "Host" header in the HTTP request, supplied by all HTTP/1.0 and HTTP/1.1 clients; this host header tells us the name of the website that the user is requesting content from.

Why?

Q: But I already have a hostname for my website; it's "www.mycompany.com". Can't I just use that?
Unfortunately, for the most part, no. That name already points at a machine on the internet - yours. On it is all the content from your website, physically connected to that number. However, there are ways of doing this - but they all involve a great deal of technical implementation on you, the customer's part, and at the end of the day you will still need to supply us with the DNS name that you use to access that content internally.
If the site we are building for you is replacing your website entirely - which our content management system and hosting solution are perfectly capable of providing for you - then of course the answer is yes, we can - but you would probably already know the answer to that question, and wouldn't be here. *grin*
Q: But I already have a website that I want to put the content under; can I make it look like the content is a part of that website, but under, say "http://www.mycompany.com/events/..."?
A: In short, possibly - "/events", in that URI, points at your server, too - and the internet's domain name system can't process that part of the URI. That means that your site has to know to make that request of our servers and present that content to the user through you. However, as mentioned above, only you can provide this functionality, as it needs to be provided by you, your system integrator, your hosting provider, or your technical partner responsible for the site connected to that domain name. Enabling this functionality is a change to your website, not a change to ours, and you will still need to supply us with the DNS name that you use to access that content internally.
For the more technically minded:
  • You can implement a proxy server on your primary webserver (or servers); this is known as a "reverse proxy" configuration, and allows you to proxy the contents of a whole server, request by request, and cache a copy locally as if you were the originator of that content. In some cases, on large-scale deploys, you may already be using a reverse proxy configuration, so this may well be possible. Users who wish to do this will be responsible for correcting links in the content where they appear to point at their reverse proxy; most reverse proxy implementations have a mechanism for doing this as a part of the software or hardware used to implement it. Check with your vendor, system integrator, or hosting provider to find out whether you can take this option, and what the process you would go through to implement this would be. Your reverse proxy can then be configured to translate "/events" into a request to the service you are purchasing from us.
  • You can configure some load balancers to rewrite-and-forward requests; however, it is unlikely they can also retarget all of the URLs to point at the appropriate place, or that you would want to put that much load on such critical equipment. At some point in the future (6-9 months), we will be making modifications to our system to enable us to do more 'magical' URL/URI processing; at that point, we may have more support for users in this configuration by allowing our side to change the URIs it provides back to customers according to the customers' own configuration - but instances where this will work smoothly and reliably today are very slim, and limited to high-end hardware installations in customer platforms. Very few have hardware or software packages capable of performing this kind of global load balancing for specific URI paths, and the kit for doing so is on the order of ~?20,000 per balancer.
  • You can write custom software to do the passthrough. Through the magic of HTTP, you can read a customer request, parse the query, reconstruct a URI for the target website, check for cached content, and request it if it isn't already available. That, however, is a mirror of what a reverse proxy already does - and nobody should be reinventing this particular wheel when so many good open source and commercial solutions for doing this are available.
Q: Why do you require a DNS name? Can't we just use the IP address?
A: Once the hostname is found in our configuration, we match it to a website in our hosting system, and apply all of the restrictions and configuration associated with that website; it determines, for example:
  • Whether or not your site contains WhatsOnWhen, LonelyPlanet, Columbus, or other destination guides;
  • Which parts of the world your site gets content for; a complex set of inclusions and exclusions can be applied to each customer account to meet the licensing restrictions and content restrictions on their service, as determined by their contract;
  • What content is visible; event categories can be included or excluded in order to meet the needs of the customer (Some customers prefer not to take 'adult' content such as gay and lesbian events, others only wish to license sport events, etc.);
  • Which, if any, XML feeds are configured for use by the customer, and what IP address restrictions are placed on the use of those feeds;
For this reason, customers will need to supply us with a DNS name on which their service will be used. That name is the key that search engines use to index your content, the key that our system uses to locate your configuration and metadata, and the key that determines how the rest of the URL (for customers using dynamic URL processing in the hosting platform to get a customised URI path meeting statistical requirements) is processed.

How-To Questions

Q: How do I create a domain name?
A: You can create any DNS domain name of your choice through your preferred DNS registrar, or preferrably, and in most cases more appropriately, create any subdomain of your existing website in your own DNS nameserver.
When you create the DNS entry in the server, you will inform it that the "A record", the IP address connected to that DNS name, is 217.204.10.78, and inform us of the name you will be using. This maps the IP address of our primary webserver directly to your DNS name, so that when users type in the name you have chosen into their web browser, they find our server. An example record in a BIND config file format might look like
wibble.yoursite.com IN A 217.204.10.78
The base feed URL for your new site would then be http://wibble.yoursite.com/sisp/index.htm, and can be configured in your feed processing software.
If the DNS name is being created for your main website - if WhatsOnWhen is building and hosting the whole of your internet site, that DNS name should be www.yoursite.com; in all other cases, it should be a subdomain of that domain which isn't www; some customers who take event content use events.yoursite.com; others prefer names like travel.yoursite.com, or whatson.yoursite.com. Even guides.yoursite.com is appropriate.
If the DNS name is being created for an XML feed, then it should be something appropriate; however, it will not be something that customers see directly, so the name is inconsequential. Names which will be seen by customers should be agreed upon by your marketing or branding people to ensure that the name is appropriate to your customer base and requirements; feed names are entirely inconsequential as to what the actual content is; feel free to create an entry for wowxml.yoursite.com, foo.yoursite.com, or any other name of your choice.
Q: How long will this take to do?
A: The total amount of technical time needed to either edit the entry in a unix-based or Windows-based domain name server run by an organisation is on the order of five to ten minutes; once configured, propagation of the DNS records across the internet can take anywhere from 24 to 48 hours - therefore, we require that this configuration change be made a minimum of two days before the intended ship date of the live service; more importantly, we encourage you to create the name as soon as you have made a decision, in as far advance of the ship date as possible, so we can test your configuration.
You'll take longer to read this document than it will for a techie to create the name you ask for.

Frequently Asked Questions: Hosting Customers

Q: This seems like a lot of effort for nothing.
A: Having the site name be a subdomain of your main site has several advantages to you, as well as several advantages to us:
  • Search engines will associate traffic on your branded site as a part of the family of domain names which make up your website. If we hosted them under our own domain name, we would get the search benefit, not you - and part of the point is to ensure that the benefits of the content to search engines goes to the customer, not to us.
  • Customers don't need to worry about whether or not they're "leaving" your site; the look and feel of the hosted platform has probably been painstakingly built to ensure it matches the look and feel of your site - why disrupt the customer experience by changing the URL?
  • And last but not least: it provides us an easy mechanism by which to separate out our customers' logs, hits, and tracking information.
  • If you ever leave us (who would?), you can redirect the traffic to your own site, or to another partner; the site stays under your control at all times, giving your business the most flexibility in terms of controlling the partner relationship. It empowers you, the customer.
In short, it provides our customers a better service, and it provides us ease of management. Win-win.

Frequently Asked Questions: XML Feed Customers

Q: So; I create an arbitrary domain name in a DNS server - whatsonwhen.foo.com, for example, and point it at IP address 217.204.10.78? And tell you the list of IP addresses which will use the feed?
A: Exactly. When a request for the XML feed at wibble.foo.com comes in, we will verify that the request comes from an IP address which we know is allowed to request the feed, and use the configuration associated with wibble.foo.com to provide you that feed. It doesn't matter what the name is; only that we know it, and it points at the IP address listed above.
All that matters is that you create a DNS entry for any arbitrary name of any kind, configure your feed processors to request that from the live servers when your feed goes live, and inform us of what that DNS name will be so we can update our configuration. You create the DNS entry on your servers by creating an A record pointing at 217.204.10.78.