QSYS URL-Paths

QSYS URL-Path Format

Web Server/400 represents URL-paths pointing into QSYS in a way very similar to how the new IFS represents them. The following rules summarize how IFS represents objects in QSYS:

Host objects are represented by the object name followed by an extension that indicates the object's type.
All paths to QSYS objects begin with /qsys.lib.
The QSYS library is the only library that can contain other libraries.
The only two object types that can contain other objects are libraries and files. A library can contain any object type except members and other libraries (excluding QSYS). The only object type that files can contain are members.

For instance, the file PRICES stored in library CORPDATA could be represented as /QSYS.LIB/CORPDATA.LIB/PRICES.FILE. If the PRICES file had a member called WIDGET, then that member could be represented as /QSYS.LIB/CORPDATA.LIB/PRICES.FILE/WIDGET.MBR.

Web Server/400 and IFS Differences

Listed here are the major differences between the way IFS handles files in QSYS and the way Web Server/400 handles them:

Object type extensions are not always necessary: With Web Server/400 the object type extensions are optional. If the object name is enough to make the object unique, the extension is not needed. If more than one object in a library or file has the same name, the object type extension is required. Note: When determining if an object's name is unique, only object types of .LIB, .FILE, .MBR, and .PGM are considered.
Content Type extensions can be included: A URL-path can optionally include a Content Type extension on files and members. The Content Type extension is not part of the actual object name and must come after the object type extension if one is present.
A file's member is defaulted if not specified: If a file is specified with no member, this is the same as specifying the file with its first member.
A file with a trailing slash returns a dynamic index: A URL-path that includes a trailing slash after an object that has type .FILE is considered a request for a dynamic index.
Symbolic links to objects in QSYS: Some restrictions exist for having symbolic links in IFS to objects in QSYS.

QSYS URL-path Examples

For these examples, assume that /NATIVE/ is aliased to /QSYS.LIB/ in QSYS and that CORPDATA is in the Include Libraries configuration value but not in the Script Libraries configuration value. With this setup, each of the following requests would be handled as described.

A URL-path of /NATIVE/CORPDATA/PRICES/WIDGET: The member /QSYS.LIB/CORPDATA.LIB/PRICES.FILE/WIDGET.MBR would be sent assuming that QSYS.LIB does not contain a file named CORPDATA.FILE. If this file did exist, this URL-path would be rejected as not found since the CORPDATA name wouldn't be unique in its library.
A URL-path of /NATIVE/CORPDATA.LIB/PRICES/WIDGET.MBR.HTML: The member /QSYS.LIB/CORPDATA.LIB/PRICES.FILE/WIDGET.MBR would be sent as HTML.
A URL-path of /NATIVE/CORPDATA.LIB/PRICES.TXT: In this case, the first member of the file /QSYS.LIB/CORPDATA.LIB/PRICES.FILE would be sent as plain/text.
A URL-path of /NATIVE/CORPDATA/PRICES/: Because of the trailing, slash a dynamic index of /QSYS.LIB/CORPDATA.LIB/PRICES.FILE/ would be returned.

Providing Access to QSYS Libraries

Because of the limited hierarchy depth found in the QSYS file system, a different mechanism is used to protect non-Web content data from being served by Web Server/400. The other file systems have a Document Root configuration value that limits access to Web documents to a subdirectory of the Document Root. The QSYS file system has, instead, a configuration value that lists all libraries that Web Server/400 can serve documents out of. If the library specified by a URL-path is not included in the Include Libraries configuration value, the request is rejected.

A wildcard of an asterisk can be used to indicate that any library that has the same beginning as the library in the Include Libraries directive, up to the asterisk, is accessible.