Escutcheon Columbia University Libraries Digital Program
CUL Name Resolver — Overview

          Path: Digital Library Projects  :  Name Resolver  :  Overview


The CUL name resolver is a cgi program written in perl.   A single argument (unique key) is passed to it as in the following example:

Resolver Data Format

Resolver data is stored in a flat binary database file (dbfile). Access is via the key only. The structure of the file is as follows:

  • key
  • content

    The content is parsed and split into the following fields:

  • local url -- url for local (on-campus) users
  • remote url -- url for remote users has 3 possible forms:
    1. [blank] local url is then substituted
    2. a token (resolver generates response based on token value, valid tokens are: 1 (construct proxied URL), 2 (construct proxied URL and redirect both local and remote users to this URL))
    3. some other URL
  • notes -- free-text field

    Parsed examples:

    ATJ2566 ID=76509746 1 standard proxied resource
    proquest-direct 1 also proxied
    abia   not proxied

    NB: the absence of a remote URL does not imply that a resource is unrestricted; it may mean that authentication and access control is handled elsewhere, as in the following example:

    Design aspects related to Stability and Performance

    Earlier versions of the resolver stored proxied URLs but to increase flexibility (including failover of proxy servers) the resolver generates these URLs on the fly when it encounters a numeric token in the remote URL field. As new remote access technologies are introduced, the rewrite rules can be updated to accomodate them; in our current implementation the proxy host name is read by the resolver from an external file which allows an external script to monitor proxy server availability and modify the content of this file as necessary.

    Exceptions and special processing

  • VPN -- The resolver determines whether a user is on or off campus based on the dns name of the computer running the browser. There are a number of split tunnel VPNs however which need to be accomodated; browsers at these addresses are directed as if they are off campus.

  • on campus proxying -- in some cases authentication to a remote resource is brokered by our ezproxy software; is these cases on campus users must be directed to the proxy server; this is accomodated by the use of the token "2". When the remote URL has a value of "2", a proxied URL is generated and all users are redirected to it.

    Error handling, logging

    If a non-existent key is passed to the resolver

    the user is directed to a generic error page. In addition, email to Systems staff is generated indicating the key as well as the page with the faulty resolver link (if any) for follow-up.

    For each use of the resolver a log entry is generated. We log: time and date, resolver key, whether user is on campus (L), off campus (R), or has generated an error (E), the referring page, and url the resolver supplied.

    Input, and update

    There are four input streams into the resolver tables at present:

    1 - a very small amount of manual inputting and editing is done for entries not associated with cataloged material.

    2 - we generate as needed, feeds from our LMS for bulk loaded records which is automatically loaded into the resolver; batch loaded entries are flagged to trigger review of remote access settings.

    3 - catalogers update the resolver via a web interface as material is cataloged.

    4 - There is also an adhoc resolver entry form which accepts a URL, generates a unique key, and adds the key/url pair to the resolver. This is commonly used for document delivery as well as courseware

    NB -- The resolver update procedures write to a flat text file which is read and parsed in preference to the db file; this file is periodically reviewed, edited as necessary and loaded into the database.

    Maintenance, querying and temporary redirection

    We provide a series of online forms for library staff to interact with the resolver:

    Forms on this page allow librarians to :

  • query the resolver to determine the underlying URL associated with a key
  • report URL changes to Systems staff
  • temporarily redirect a resolver entry to a customized "out of service" page
  • restore a redirected service to its usual URL

    The redirection mechanism is internal to the resolver code and does not require updating of the resolver flat file or db file. Before looking for a URL in its file/db the resolver checks a special directory for a file with the same name as the key which was passed to it. The existence of such a file indicates that the associated resource is unavailable for some reason. The contents of this file, if any, are interpolated into the text of an otherwise generic error message indicating that the resource is unavailable. These files are created, populated and removed directly by librarians without Systems Office intervention. Transactions related to the creation and deletion of these files are logged.

    Specialized resolver variants

    A special-purpose resolver for electronic reserves has also been put into production. It differs primarily in that the user is presented with a copyright confirmation dialog before being redirected to the resource. A variety of specialized forms provide input into this resolver:

  • Columbia Libraries    Digital Program
    Last revision: 01/21/05
    © Columbia University