Hostname Migration - Hosted HTTP redirects

Requests of the form "I want <this url> to display <this content>" are fairly frequent. However, we need to unpack some of the details of how this works to fulfill them.

DNS redirection of a hostname

If we do a DNS mapping from hostname.mit.edu to www.someotherhost.org (or the IP address that that responds on) the server at the other end handles serving the content. If an entire hostname is being redirected, and the host at the destination is able to provide an Apache configuration that can recognize traffic intended for the MIT hostname and respond to it appropriately, this has good results.

See: Hostname Migration - Validation ahead of DNS change for some of the setup details.

In some circumstances, there are limitations on providing this:

It's up to the hosting provider at the other end to provide an appropriate configuration.
Our DNS configuration policies may not be compatible with the provider's.
Some internal services (such as github.mit.edu, Stellar, Wikis) don't provide SNI configurations to allow you to map a separate hostname to them.

HTTP 301/302 Redirects

If we maintain control of the hostname, and when it is accessed, we serve an HTTP redirect, we are essentially telling the visitor "go over to this URL instead". The visitor will see in their navigator bar, the destination url.

F5 Appliance Managed by Server Operations

Server Operations uses an F5 Big IP appliance for most of the dedicated redirects that we host. Customers being supported here should be:

MIT Departments Labs and Centers, other official MIT business
Able to provide a valid cost object (for tracking) and technical contact

HTTP redirects on a Managed Server

Any web server can serve redirects. Concerns:

It's more appropriate to allocate a VIP on the F5, than to allocate an SNI hostname on a managed server just for a redirect
Redirects should not be hosted on Drupal Cloud
Redirecting a sub-page of a website to another destination is often a reasonable choice
Doing a redirect as a "lockout" or as a transitional step is often reasonable in the managed server space

Redirects on scripts.mit.edu

It's possible to redirect a hostname on the SIPB Scripts service to an external location, in the site's .htaccess file. This is an option for a name that doesn't fulfill the criteria for being served on Ops's F5 appliance. Concerns:

This isn't a supported service and IS&T can't provide either configuration or runtime support.
The Script service is maintained by student volunteers, and best used in a self-service manner.

Proxying redirects

It's theoretically possible for a hosted redirect to proxy the content at the origin, and serve this up under the local name. This has a number of potential problems, and Server Operations doesn't have a validated configuration that's working as a general solution. (So in most cases this is not available at all.)

Problems we've hit:

The html content itself contains directives that route the visitor back to the external hostname immediately.
Outages at the origin of the data impact our monitoring.
We must unencrypt/reencrypt any SSL that's in use.

F5 Appliance redirects for web.mit.edu content

In a few rare cases, the desired end result is to serve web.mit.edu content under a different hostname. This can be done (and is well tested) on the F5 (because we have specific control over the back end).

Putting non-MIT hostnames on Drupal Cloud

This can be done via an F5 proxy, but there's judgement involved as to whether this is a good use of resources. It isn't generally available for personal/vanity domains, but is available for institutional collaborations under some circumstances.

Proxying redirects on scripts.mit.edu

This is believed to work; see caveats above concerning lack of support.