URL Locations

OS/400 File Systems

Where Web Server/400 stores Web content differs from most Unix and PC based Web servers. This is due to the rich variety of file systems that OS/400 supports. Each file system is available for different purposes, each having its own uses and specialties.

QSYS: QSYS is what most people refer to as the file system of OS/400. It consists of libraries and objects. Some of the types of objects are database files, programs, and spooled files.
QDLS: The common names for this are Document Library Services (DLS) or shared folders. Office Vision/400 uses DLS to store data generated by Office users. Shared folders is the file system accessible by PC Support/400 clients.
Root: With the release of V3R1 of OS/400, a new Integrated File System (IFS) was introduced. IFS is an all-encompassing file system that includes all of the above file systems and additional ones. The "Root" file system is part of IFS and is based on Unix. In these pages, "Root" will refer to all file systems in IFS except QSYS and QDLS. IFS can be accessed through a new set of commands and APIs and also through the new Client Access/400 clients.

In comparison, a Unix product would only access data off of one file system (one similar to the Root file system). On an AS/400, supporting only a subset of the above file systems would be extremely limiting. Each file system has its own advantages and uses making them all useful for storing data served by a Web server.

Uniform Resource Locator

A Uniform Resource Locator (URL) describes where to find something of interest stored somewhere on the Internet. A URL has enough information in it to uniquely describe any resource on any host anywhere in the world. The basic form of a World Wide Web URL is:

http://server:port/URL-path?Query
String

where,

http://: is the protocol being used. Over the Web, the Hypertext Transfer Protocol (HTTP) is used. This is the language spoken between servers and browsers.
server: is the fully qualified domain name of the machine that contains the resource.
port: is the socket port on the host machine that is running the HTTP server. The :port is optional. If the port is not included, it defaults to port 80.
URL-path: is the fully qualified, hierarchical path to the resource. This can be based on the machine's file system hierarchy or an arbitrary (but unique) naming scheme. An empty URL-path is valid.
Query String: The Query String begins with the first unescaped question mark ("?") after the URL-path. This is generally used to pass parameters into scripts or to modify the default behavior of serving a Web document.

URL Examples

http://www.inetmi.com/samples/document.html: Identifies the file document.html in the samples directory on the host www.inetmi.com. The request is an HTTP request that is handled by the Web server running on port 80 (the default).
http://www.inetmi.com:2064/samples/: Identifies the directory samples on the host www.inetmi.com. The request is an HTTP request that is handled by the Web server running on port 2064.
http://your.host.net/company/info/employee/profile/jane_doe.jpg: Identifies the image jane_doe.jpg in the /company/info/employee/profile/ subdirectory on the host your.host.net. The request is an HTTP request that is handled by the Web server running on port 80 (the default).

How Web Server/400 Finds a Web Document

Three factors come into play when the server attempts to locate the resource that is requested by the browser:

the URL-path,
the source file system, and
the root of all documents on that file system.

URL-Paths

Once a server starts handling a request from a browser, the URL-path is the most interesting portion of a URL. The other portions of a URL are responsible for correctly routing the request to the proper host. The Web server then takes the URL-path and determines what should be sent back to the browser.

URL-paths are typically hierarchical with the structure indicated by names separated by slashes ("/"). This is very similar to path names on Unix or PC file systems or OS/400's new IFS. In fact, for the most part Web Server/400 does map a URL-path's hierarchy directly to IFS's directories and files. So when a browser requests a URL-path of /abc/xyz.html, the server looks for a directory called abc with a file in it called xyz.html.

The URL's Source File System

Web Server/400 determines which file system contains the data needed to serve a request through configuration values, aliases, and the URL-path. The URL-path is checked to see if it begins with a configured alias. If it does not, the Default Source Type configuration value indicates where the URL-path points to. If the URL-path does begin with an alias, the alias can indicate a file system to use other than the default.

The Source File System's Document Root

All three file systems, QSYS, QDLS, and Root, have a different location to begin looking for files in that file system. This location is referred to as the Document Root. All URL-paths are relative to the appropriate Document Root. The Root and QDLS file systems each have configurable document roots that are quite similar: Document Root and Document Root QDLS, respectively.

The QSYS file system really has two document roots.

The Document Root QSYS is similar to the Root and QDLS document roots. QSYS's document root is configurable and URL-paths are searched for in this library. However, not all URL-paths are considered relative to the Document Root QSYS. Only URL-paths that do not include an explicit library are relative to the Document Root QSYS library. So, a URL-path that contains only a file and member would be considered relative to this special library. This is especially useful when the Default Source Type is set to QSYS. Then the Index Name Web document is pulled from the Document Root QSYS library if it doesn't have a path on the beginning of it. Note: Be sure to add the library specified by Document Root QSYS to the Include Libraries configuration value.
The other QSYS document root is QSYS itself. All references to URL-paths that have a library in them are relative to QSYS. This is because all libraries are in QSYS and QSYS is the only library that can contain libraries. This limited hierarchy forces URL-paths with library names to be relative to QSYS.

An Example

An example is in order. Assume that the Default Source Type is the Root file system and that an alias exists that maps all /library/ references to /qsys.lib/ and that the Document Root for the Root file system is set to /webpages/. If a user requests a URL-path of /info/page.html, then the server would look in the Root file system for the file to serve since info is not aliased and the Default Source Type is the Root file system. The server would then make the URL-path relative to the Document Root. This would cause it to look for the file /webpages/info/page.html.

If the user requests a URL-path of /library/ProdData.lib/Prices.file, the server would look in the QSYS file system for the file since the alias maps all references beginning with /library/ to files in QSYS. It would then look for the file PRICES in the library PRODDATA.

Special URL-paths

Although a URL-path is generally directly mapped to a file system's directory structure, this doesn't have to be the case. In several cases, Web Server/400 defines a logical URL-path to a physically different file system path. The usual reason for this mapping is to fit a feature of OS/400 into something consistent with typical URL-paths. This makes for a more seamless integration of OS/400 concepts with the WWW.

The details of URL-paths are separated out by file system and type of resource being referred to: