ServerDispatchOperations

OPeNDAP servers provide an interface through which clients can access data held on the server. The server can provide sub-setting and, in some cases, additional pre-processing operations on the requested data. The protocol through which OPeNDAP servers provide these data services is called the Data Access Protocol (DAP). The current version of the DAP is version 2, so The DAP is usually specified as DAP2.

In addition to DAP2 responses, most OPeNDAP servers provide a number of additional services such as:

• A navigation interface for browsing the data storage hierarchy.
• File access.
• Version reporting.
• Help pages and other documentation.
• THREDDS catalog views of the data system.

Request dispatch is the process through which an OPeNDAP Server determines what actual piece of code is going to respond to a given incoming request. In a perfect world, the identified piece of software will generate the type of response the client intended to invoke on the server, or at worst a sensible error response such as a web page or a serialized DAP2 error object.

Anatomy of a URL

For the sake of clarity the following definitions will be used in this document:

Request URL

The complete URL as submitted by the requesting client.

Constraint Expression (CE)

Everything following the "?" character in the request URL

Datasource URL

The request URL with the CE removed (the "?" and everything after it.)

Projection

The things that are being requested. The part of the CE prior to the first "&" character. This is where individual variables from a dataset can be requested, or if no variables are specified then all of the varaibles will be requested. The end of the projection is marked by the end of the request URL, or by the presence of the first "&" character.

Selection

The conditions that must be met for the requested things. The remainder of the request URL after the datasource URL and projection have been removed.

Request suffix

The collection of characters after the last occurrence of the "." characters in the datasource URL. For many requests the request suffix may not exist, or it may be nonsensical.

Datasource

The datasource URL with the "scheme" (typically http://), the server[:port], servlet context, and CE removed.

Examples

1

Request URL: http://localhost:8080/opendap/data/nc/fnoc1.nc.dds?sst&time<3

CE: sst&time<3

Datasource URL: http://localhost:8080/opendap/data/nc/fnoc1.nc.dds

Projection: sst

Selection: time<3

Request suffix: dds

Datasource: /data/nc/fnoc1.nc

2

Request URL: http://localhost:8080/opendap/data/nc/fnoc1.nc.html

CE:

Datasource URL: http://localhost:8080/opendap/data/nc/fnoc1.nc.dds

Projection:

Selection:

Request suffix: html

Datasource: /data/nc/fnoc1.nc

3

Request URL: http://localhost:8080/opendap/data/nc/

CE:

Datasource URL: http://localhost:8080/opendap/data/nc/

Projection:

Selection:

Request suffix:

Datasource: /data/nc/

4

Request URL: http://localhost:8080/opendap/data/nc/README.txt

CE:

Datasource URL: http://localhost:8080/opendap/data/nc/README.txt

Projection:

Selection:

Request suffix:txt

Datasource: /data/nc/README

Don't count on the consistent use of these terms elsewhere in the OPeNDAP literature:

Hyrax Dispatch

The Hyrax front end (OLFS) handles each incoming request by offering the request to a series of DispatchHandlers. Each DispatchHandler is asked if it can handle the request. The first DispatchHandler to say that it can is then asked to handle the request. The OLFS creates an ordered list of DispatchHandlers by reading tits configuration file.

The order of the list is significant. There is no guarantee that two (or more) DispatchHandlers may claim a particular request. Since the first DispatchHandler in the list to claim a request gets to service it, changing the order of the DispatchHandlers can change the behaviour of the OLFS (and thus of Hyrax).

The usefulness of this dispatching scheme is that it creates extensibility. If a third party wishes to add new functionality to Hyrax one way is to write a DispatchHandler. To incorporate it into Hyrax they only need to add it to the list in the olfs.xml and add the java classes to the Tomcat lib directory.

Order of Dispatch Operations In Hyrax

The DispatchHandlers are called in the following order:

1. Special Request Handler
2. Version Response Handler
3. Directory Response Handler
4. DAP2 Response Handler
5. File Response Handler
6. THREDDS Response Handler

Each DispatchHandler evaluates the incoming request by analyzing the request URL to determine if in fact it can handle the request.

Special Requests

Hyrax and other servers may support some special requests. These may be a secure server administration interface, help information, server status, or system properties. There is no clearly defined set of special responses, and their implementation is left up to the various server developers.

Hyrax currently supports:

• help - The URL http://your.host:port/opendap/help will take you to an help web page.

DAP2 Service

DAP2 service requests are identified by analysis of the URL as follows:

If the URL