UW Technology offers URL Forwarding and Masking services, but there are often questions about what they are and how they differ, as well as how they’re implemented.

The basic difference is that URL Forwarding is a redirect service which can be configured to have any URL as the destination (and the browser’s URL field will change to reflect the new location), while URL Masking only works for depts.washington.edu, faculty.washington.edu, staff.washington.edu, and courses.washington.edu (with the browser’s URL field not changing). If you are running your own server, chances are you do not need these services since you can configure the web server to both answer as whatever URL you choose and to redirect any additional names you require.

URL Forwarding

As mentioned, URL Forwarding is a redirect service which can go to any URL. For example, drama.washington.edu uses URL Forwarding to go to depts.washington.edu/uwdrama/. You can see the redirect in action with curl:

$ curl -I drama.washington.edu
HTTP/1.1 302 Found
Date: Mon, 09 Feb 2009 20:28:00 GMT
Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8d DAV/2 mod_pubcookie/3.3.2c mod_uwa/3.1.5
Location: http://depts.washington.edu/uwdrama/
Content-Type: text/html; charset=iso-8859-1

As soon as your browser connects to drama.washington.edu it will try to fetch depts.washington.edu/uwdrama/ and all subsequent requests will stick with the latter address.

URL Masking

The implementation of URL Masking is somewhat similar to an ISP which does mass virtual hosting. It uses CNAME entries to create aliases in DNS, all pointing to the appropriate destination host, which in turn knows how to map the masked hostname to the right directory. For example, coenv.washington.edu points to depts.washington.edu:

$ host -r coenv.washington.edu.
coenv.washington.edu. is an alias for depts.washington.edu.

When depts.washington.edu detects that a request is really for coenv.washington.edu, it internally treats the request as if it were for depts.washington.edu/coenv/ and all URIs will be adjusted so links will correctly work. In other words, a request for coenv.washington.edu/image.gif would be treated as depts.washington.edu/coenv/image.gif.

SSL support

SSL is not supported with URL Forwarding, but once the forwarding happens SSL can be used on the destination host. SSL is completely unsupported with URL Masking. In both cases SSL doesn’t work is because it’s infeasible to support hundreds of SSL certs; each forwarded name would require a dedicated IP address on each of the servers in the destination cluster.

With both forwarding and masking, trying to connect with https: would give you a certificate warning. With URL Forwarding, however, you can begin to use SSL after the forwarding is complete. Taking the drama.washington.edu example, you will get the warning if you try to https://drama.washington.edu/. After the redirect, your requests would be going to https://depts.washington.edu/uwdrama/, and the URL matches the SSL cert for depts.washington.edu. Pubcookie will always work, since it’s configured to work with depts.washington.edu.

Since URL Masking never changes the URL, the cert mismatch will always happen. In addition, Pubcookie won’t work because it isn’t configured to work with masked URLs (such as coenv.washington.edu), so you’ll get an error message instead of a login screen.

Implementation

URL Forwarding and URL Masking use the same configuration file which has entries such as:

coenv.washington.edu  depts.washington.edu/coenv
drama.washington.edu  depts.washington.edu/uwdrama

If the DNS is pointing to the dedicated URL Forwarding servers then URL Forwarding will be used. However, if DNS is pointing to depts.washington.edu, staff.washington.edu, faculty.washington.edu, or courses.washington.edu, URL Masking will be used.

Because of the large number of entries, the URL Forwarding servers have a custom Apache module which reads in the config file and enables forwarding. The config file doesn’t differentiate between forwarding and masking, so the module enables forwarding for all entries and assumes it will only need to serve domains which point to the forwarding servers. Each entry is small enough that memory isn’t a problem.

Web servers which support URL Masking have a different custom Apache module which reads the same config file and will support URL Masking for hosts which match the ServerName. For example, depts.washington.edu will configure itself to handle masking for all entries for which the right hand side starts with depts.washington.edu. As with URL Forwarding, the masking module relies on the fact that DNS is used to configure whether entries are used for masking or forwarding. As mentioned above, it changes the URLs to be relative to the masked URL. Log entries contain the full URI (after masking) so entries can be attributed to the right location.

The masking module interacts with other local modules, and both the forwarding and masking modules work with local config files, so it is infeasible to use them on other servers.

Other DNS issues

When signing up for URL Forwarding or URL Masking you’ll see a warning that the hostname must begin with www. The reason for this requirement is that the DNS entries are best done with CNAME records, rather than manually-maintained individual addresses; if a domain already exists, you can’t add a CNAME record for that zone, but you can add a CNAME entry named www. The forwarding servers, as well as depts.washington.edu, et. al., are load-balancing clusters and hosts which are not responsive are automatically removed from the appropriate clusters. A CNAME entry causes a separate DNS lookup for the destination, so the query will be done for the cluster itself, and only active members will be used.

You may have noticed that neither of the two examples cited above begin with www. Since coenv.washington.edu is not actually a domain, NOC can put both coenv and http://www.coenv into the washington.edu zone file as CNAME records to depts.washington.edu. Both coenv.washington.edu and http://www.coenv.washington.edu are in the URL Masking config file and are correctly masked.

The drama.washington.edu case is a little different. The entry for http://www.drama.washington.edu is a CNAME record to the forwarding server, so it conforms to the normal case. However, drama.washington.edu is its own zone, so there must be individual A records. Because of this, there is a risk that one of the forwarding servers could be down, causing accesses to fail if the address of the down server is used. Another possible failure mode is if the server addresses were changed and not all the records were updated, although every effort would be made to avoid this situation when server addresses are changed. Since drama.washington.edu is only used for URL Forwarding (so the forwarding servers are only contacted once for the initial request and after that the browser is connecting directly with depts.washington.edu), the impact of an outage is arguably limited, but it would be for that first connection. If one of the two forwarding servers were down, there would be a 50-50 chance that the request would succeed anyway, and for many browsers, a second attempt would connect you with the other server and you’d get the redirect.

As a disclaimer, I am neither involved nor familiar with how the NOC decides whether to manually maintain individual addresses for URL Forwarding or URL Masking.