The document describes EBCDIC-to-ASCII conversions on text files that it serves out of the QSYS.LIB file system.

Text files
The IBM HTTP Server for i does an EBCDIC-to-ASCII conversion on any text files that it serves out of the QSYS.LIB file system. Files with a member type of HTML or TXT fall into this category. The integrated file system (IFS) does not allow a QSYS.LIB file to be created with an ASCII CCSID. Therefore, the HTTP server is designed to regard all QSYS.LIB text files as EBCDIC files. The HTTP server always performs EBCDIC-to-ASCII translation on text files before serving them.

In addition, any unknown (not MIME defined) text subtype will be treated as text/plain, so it will also be converted from EBCDIC-to-ASCII. No additional processing will be done on the resulting text.

Non-text files
There may be instances when it is desirable to serve non textual data from the QSYS.LIB file system. For example, one may wish to store information for a PC application in the QSYS.LIB file system. This is covered in HTTP specifications by the "application" media type.

To serve application data, one would set the member type to something specific that would identify the file's content type. The MIME type associated with the member type would be set such that the HTTP server recognizes the encoding for the file as binary. For example, application/octet-stream. In this case, the HTTP server serves such files in binary (with no conversion).

Keep in mind that QSYS.LIB is a fixed-record-oriented file system. This record nature might cause problems when serving stream files, especially if the web administrator does not create the QSYS file with an adequate record length. Therefore, it is recommended that you serve these type of files out of the IFS "root" (/) file system.

By default, the HTTP server defines several MIME types that have a text subtype. Many other default MIME types have binary encoding. The list of default MIME types and their associated content type is covered in the IBM HTTP Server Documentation. See the AddType directive. 

The HTTP specifications do not explicitly cover ASCII/EBCDIC conversions, and MIME type does not provide a mechanism for specifying conversion CCSIDs. If you want to serve ASCII content from the QSYS.LIB file system MIME-types with binary encoding, one of the following will be required:

A simpler solution may be to store the file in the integrated file system (IFS) and serve it from there.

Example
As an example, assume that you have a spreadsheet file that you wish to store in the QSYS.LIB file system. The file is saved with an "ssh" QSYS member type. In your HTTP server's configuration file you have specified:

      AddType application/octet-stream .ssh

The MIME-Type for any "ssh" files indicates that the content type is non-textual (binary). Therefore, this file will be read from the file in binary and served as such, without any conversions. If the file is stored in binary (CCSID 65535) and the client expects binary, then this should work fine. If the file is stored in EBCDIC it will be served as EBCDIC content to the client. This may not be the desired result.

If client machines require ASCII content for this data, a better approach is to store this file in the IFS "root" (/) file system with the appropriate ASCII CCSID.

A brief description about the Application Media Type and the Octet-Stream subtype for the MIME-Type Application/Octet-Stream 8bit.

Application media type
The "application" media type is to be used for discrete data which does not fit in any of the other categories, and particularly for data to be processed by some type of application program. This is information which must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" media type include file transfer, spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) material. (The latter, in particular, can pose security problems which must be understood by implementors, and are considered in detail in the discussion of the "application/PostScript" media type).

This paragraph tell us that an expected use of the application media type is to use it for spreadsheet data, but it never mentions a word about conversions between character sets being enforced or even necessary. We think that the specification never considered a case where EBCDIC-to-ASCII character conversions would be necessary. The following text defines the octet-stream subtype:

Octet-stream subtype
The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. The set of currently defined parameters is:

(1) TYPE -- the general type or category of binary data. This is intended as information for the human recipient rather than for any automatic processing.

(2) PADDING -- the number of bits of padding that were appended to the bit-stream comprising the actual contents to produce the enclosed 8bit byte-oriented data. This is useful for enclosing a bit-stream in a body when the total number of bits is not a multiple of 8.

Both of these parameters are optional.Octet-stream is defined as an arbitrary binary data subtype, which means that the HTTP server must not convert anything in the message body before serving it.

Since the IFS "root" (/) file system gives you much greater flexibility in working with non-text stream files, the recommendation is to serve these files from IFS.