+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <meta name="generator" content="HTML Tidy, see www.w3.org" />
-
- <title>The Apache EBCDIC Port</title>
- </head>
- <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-
- <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
- vlink="#000080" alink="#FF0000">
- <!--#include virtual="header.html" -->
-
- <blockquote>
- <strong>Warning:</strong> This document has not been updated
- to take into account changes made in the 2.0 version of the
- Apache HTTP Server. Some of the information may still be
- relevant, but please use it with care.
- </blockquote>
-
- <h1 align="center">Overview of the Apache EBCDIC Port</h1>
-
- <p>Version 1.3 of the Apache HTTP Server is the first version
- which includes a port to a (non-ASCII) mainframe machine which
- uses the EBCDIC character set as its native codeset.<br />
- (It is the SIEMENS family of mainframes running the <a
- href="http://www.siemens.de/servers/bs2osd/osdbc_us.htm">BS2000/OSD
- operating system</a>. This mainframe OS nowadays features a
- SVR4-derived POSIX subsystem).</p>
-
- <p>The port was started initially to</p>
-
- <ul>
- <li>prove the feasibility of porting <a
- href="http://dev.apache.org/">the Apache HTTP server</a> to
- this platform</li>
-
- <li>find a "worthy and capable" successor for the venerable
- <a href="http://www.w3.org/Daemon/">CERN-3.0</a> daemon
- (which was ported a couple of years ago), and to</li>
-
- <li>prove that Apache's preforking process model can on this
- platform easily outperform the accept-fork-serve model used
- by CERN by a factor of 5 or more.</li>
- </ul>
- <br />
- <br />
-
-
- <p>This document serves as a rationale to describe some of the
- design decisions of the port to this machine.</p>
-
- <h2 align="center">Design Goals</h2>
-
- <p>One objective of the EBCDIC port was to maintain enough
- backwards compatibility with the (EBCDIC) CERN server to make
- the transition to the new server attractive and easy. This
- required the addition of a configurable method to define
- whether a HTML document was stored in ASCII (the only format
- accepted by the old server) or in EBCDIC (the native document
- format in the POSIX subsystem, and therefore the only realistic
- format in which the other POSIX tools like grep or sed could
- operate on the documents). The current solution to this is a
- "pseudo-MIME-format" which is intercepted and interpreted by
- the Apache server (see below). Future versions might solve the
- problem by defining an "ebcdic-handler" for all documents which
- must be converted.</p>
-
- <h2 align="center">Technical Solution</h2>
-
- <p>Since all Apache input and output is based upon the BUFF
- data type and its methods, the easiest solution was to add the
- conversion to the BUFF handling routines. The conversion must
- be settable at any time, so a BUFF flag was added which defines
- whether a BUFF object has currently enabled conversion or not.
- This flag is modified at several points in the HTTP
- protocol:</p>
-
- <ul>
- <li><strong>set</strong> before a request is received
- (because the request and the request header lines are always
- in ASCII format)</li>
-
- <li><strong>set/unset</strong> when the request body is
- received - depending on the content type of the request body
- (because the request body may contain ASCII text or a binary
- file)</li>
-
- <li><strong>set</strong> before a reply header is sent
- (because the response header lines are always in ASCII
- format)</li>
-
- <li><strong>set/unset</strong> when the response body is sent
- - depending on the content type of the response body (because
- the response body may contain text or a binary file)</li>
- </ul>
- <br />
- <br />
-
-
- <h2 align="center">Porting Notes</h2>
-
- <ol>
- <li>
- The relevant changes in the source are #ifdef'ed into two
- categories:
-
- <dl>
- <dt><code><strong>#ifdef
- CHARSET_EBCDIC</strong></code></dt>
-
- <dd>Code which is needed for any EBCDIC based machine.
- This includes character translations, differences in
- contiguity of the two character sets, flags which
- indicate which part of the HTTP protocol has to be
- converted and which part doesn't <em>etc.</em></dd>
-
- <dt><code><strong>#ifdef _OSD_POSIX</strong></code></dt>
-
- <dd>Code which is needed for the SIEMENS BS2000/OSD
- mainframe platform only. This deals with include file
- differences and socket implementation topics which are
- only required on the BS2000/OSD platform.</dd>
- </dl>
- </li>
-
- <li style="list-style: none"><br />
- </li>
-
- <li>The possibility to translate between ASCII and EBCDIC at
- the socket level (on BS2000 POSIX, there is a socket option
- which supports this) was intentionally <em>not</em> chosen,
- because the byte stream at the HTTP protocol level consists
- of a mixture of protocol related strings and non-protocol
- related raw file data. HTTP protocol strings are always
- encoded in ASCII (the GET request, any Header: lines, the
- chunking information <em>etc.</em>) whereas the file transfer
- parts (<em>i.e.</em>, GIF images, CGI output <em>etc.</em>)
- should usually be just "passed through" by the server. This
- separation between "protocol string" and "raw data" is
- reflected in the server code by functions like bgets() or
- rvputs() for strings, and functions like bwrite() for binary
- data. A global translation of everything would therefore be
- inadequate.<br />
- (In the case of text files of course, provisions must be
- made so that EBCDIC documents are always served in
- ASCII)</li>
-
- <li style="list-style: none"><br />
- </li>
-
- <li>This port therefore features a built-in protocol level
- conversion for the server-internal strings (which the
- compiler translated to EBCDIC strings) and thus for all
- server-generated documents. The hard coded ASCII escapes \012
- and \015 which are ubiquitous in the server code are an
- exception: they are already the binary encoding of the ASCII
- \n and \r and must not be converted to ASCII a second time.
- This exception is only relevant for server-generated strings;
- and <em>external</em> EBCDIC documents are not expected to
- contain ASCII newline characters.</li>
-
- <li style="list-style: none"><br />
- </li>
-
- <li>By examining the call hierarchy for the BUFF management
- routines, I added an "ebcdic/ascii conversion layer" which
- would be crossed on every puts/write/get/gets, and a
- conversion flag which allowed enabling/disabling the
- conversions on-the-fly. Usually, a document crosses this
- layer twice from its origin source (a file or CGI output) to
- its destination (the requesting client): <samp>file ->
- Apache</samp>, and <samp>Apache -> client</samp>.<br />
- The server can now read the header lines of a CGI-script
- output in EBCDIC format, and then find out that the remainder
- of the script's output is in ASCII (like in the case of the
- output of a WWW Counter program: the document body contains a
- GIF image). All header processing is done in the native
- EBCDIC format; the server then determines, based on the type
- of document being served, whether the document body (except
- for the chunking information, of course) is in ASCII already
- or must be converted from EBCDIC.</li>
-
- <li style="list-style: none"><br />
- </li>
-
- <li>
- For Text documents (MIME types text/plain, text/html
- <em>etc.</em>), an implicit translation to ASCII can be
- used, or (if the users prefer to store some documents in
- raw ASCII form for faster serving, or because the files
- reside on a NFS-mounted directory tree) can be served
- without conversion.<br />
- <strong>Example:</strong>
-
- <blockquote>
- to serve files with the suffix .ahtml as a raw ASCII
- text/html document without implicit conversion (and
- suffix .ascii as ASCII text/plain), use the directives:
-<pre>
- AddType text/x-ascii-html .ahtml
- AddType text/x-ascii-plain .ascii
-
-</pre>
- </blockquote>
- Similarly, any text/foo MIME type can be served as "raw
- ASCII" by configuring a MIME type "text/x-ascii-foo" for it
- using AddType.
- </li>
-
- <li style="list-style: none"><br />
- </li>
-
- <li>Non-text documents are always served "binary" without
- conversion. This seems to be the most sensible choice for,
- .<em>e.g.</em>, GIF/ZIP/AU file types. This of course
- requires the user to copy them to the mainframe host using
- the "rcp -b" binary switch.</li>
-
- <li style="list-style: none"><br />
- </li>
-
- <li>Server parsed files are always assumed to be in native
- (<em>i.e.</em>, EBCDIC) format as used on the machine, and
- are converted after processing.</li>
-
- <li style="list-style: none"><br />
- </li>
-
- <li>For CGI output, the CGI script determines whether a
- conversion is needed or not: by setting the appropriate
- Content-Type, text files can be converted, or GIF output can
- be passed through unmodified. An example for the latter case
- is the wwwcount program which we ported as well.</li>
-
- <li style="list-style: none"><br />
- </li>
- </ol>
- <br />
- <br />
-
-
- <h2 align="center">Document Storage Notes</h2>
-
- <h3 align="center">Binary Files</h3>
-
- <p>All files with a <samp>Content-Type:</samp> which does not
- start with <samp>text/</samp> are regarded as <em>binary
- files</em> by the server and are not subject to any conversion.
- Examples for binary files are GIF images, gzip-compressed files
- and the like.</p>
-
- <p>When exchanging binary files between the mainframe host and
- a Unix machine or Windows PC, be sure to use the ftp "binary"
- (<samp>TYPE I</samp>) command, or use the
- <samp>rcp -b</samp> command from the mainframe host (the
- -b switch is not supported in unix rcp's).</p>
-
- <h3 align="center">Text Documents</h3>
-
- <p>The default assumption of the server is that Text Files
- (<em>i.e.</em>, all files whose <samp>Content-Type:</samp>
- starts with <samp>text/</samp>) are stored in the native
- character set of the host, EBCDIC.</p>
-
- <h3 align="center">Server Side Included Documents</h3>
-
- <p>SSI documents must currently be stored in EBCDIC only. No
- provision is made to convert it from ASCII before
- processing.</p>
-
- <h2 align="center">Apache Modules' Status</h2>
-
- <table border="1" align="center">
- <tr>
- <th>Module</th>
-
- <th>Status</th>
-
- <th>Notes</th>
- </tr>
-
- <tr>
- <td align="left">http_core</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_access</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_actions</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_alias</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_asis</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_auth</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_auth_anon</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_auth_dbm</td>
-
- <td align="center">?</td>
-
- <td>with own libdb.a</td>
- </tr>
-
- <tr>
- <td align="left">mod_autoindex</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_cern_meta</td>
-
- <td align="center">?</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_cgi</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_digest</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_dir</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_so</td>
-
- <td align="center">-</td>
-
- <td>no shared libs</td>
- </tr>
-
- <tr>
- <td align="left">mod_env</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_example</td>
-
- <td align="center">-</td>
-
- <td>(test bed only)</td>
- </tr>
-
- <tr>
- <td align="left">mod_expires</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_headers</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_imap</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_include</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_info</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_log_agent</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_log_config</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_log_referer</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_mime</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_mime_magic</td>
-
- <td align="center">?</td>
-
- <td>not ported yet</td>
- </tr>
-
- <tr>
- <td align="left">mod_negotiation</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_proxy</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_rewrite</td>
-
- <td align="center">+</td>
-
- <td>untested</td>
- </tr>
-
- <tr>
- <td align="left">mod_setenvif</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_speling</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_status</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_unique_id</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_userdir</td>
-
- <td align="center">+</td>
-
- <td>
- </td>
- </tr>
-
- <tr>
- <td align="left">mod_usertrack</td>
-
- <td align="center">?</td>
-
- <td>untested</td>
- </tr>
- </table>
-
- <h2 align="center">Third Party Modules' Status</h2>
-
- <table border="1" align="center">
- <tr>
- <th>Module</th>
-
- <th>Status</th>
-
- <th>Notes</th>
- </tr>
-
- <tr>
- <td align="left"><a
- href="http://java.apache.org/">mod_jserv</a> </td>
-
- <td align="center">-</td>
-
- <td>JAVA still being ported.</td>
- </tr>
-
- <tr>
- <td align="left"><a href="http://www.php.net/">mod_php3</a>
- </td>
-
- <td align="center">+</td>
-
- <td>mod_php3 runs fine, with LDAP and GD and FreeType
- libraries</td>
- </tr>
-
- <tr>
- <td align="left"><a
- href="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">
- mod_put</a> </td>
-
- <td align="center">?</td>
-
- <td>untested</td>
- </tr>
-
- <tr>
- <td align="left"><a
- href="ftp://hachiman.vidya.com/pub/apache/">mod_session</a>
- </td>
-
- <td align="center">-</td>
-
- <td>untested</td>
- </tr>
- </table>
- <!--#include virtual="footer.html" -->
- </body>
-</html>
-
<tr><td><a href="platform/netware.html">Novell NetWare
</a> </td></tr>
+ <tr><td><a href="platform/ebcdic.html">EBCDIC Port
+ </a> </td></tr>
+
<tr><td> </td></tr>
<tr>
<th>Other Topics</th>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ --><title>The Apache EBCDIC Port - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body id="manual-page"><div id="page-header"><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.0</a></div><div id="page-content"><div id="preamble"><h1>The Apache EBCDIC Port</h1>
+
+ <div class="warning"><strong>Warning:</strong> This document
+ has not been updated to take into account changes made in
+ the 2.0 version of the Apache HTTP Server. Some of the
+ information may still be relevant, but please use it with care.
+ </div>
+
+ </div><div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#overview">Overview of the Apache EBCDIC Port</a></li><li><img alt="" src="../images/down.gif" /> <a href="#design">Design Goals</a></li><li><img alt="" src="../images/down.gif" /> <a href="#technical">Technical Solution</a></li><li><img alt="" src="../images/down.gif" /> <a href="#porting">Porting Notes</a></li><li><img alt="" src="../images/down.gif" /> <a href="#document">Document Storage Notes</a></li><li><img alt="" src="../images/down.gif" /> <a href="#modules">Apache Modules' Status</a></li><li><img alt="" src="../images/down.gif" /> <a href="#third-party">Third Party Modules' Status</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="overview" id="overview">Overview of the Apache EBCDIC Port</a></h2>
+
+
+
+ <p>Version 1.3 of the Apache HTTP Server is the first version
+ which includes a port to a (non-ASCII) mainframe machine which
+ uses the EBCDIC character set as its native codeset.</p>
+
+ <p>(It is the SIEMENS family of mainframes running the <a href="http://www.siemens.de/servers/bs2osd/osdbc_us.htm">BS2000/OSD
+ operating system</a>. This mainframe OS nowadays features a
+ SVR4-derived POSIX subsystem).</p>
+
+ <p>The port was started initially to</p>
+
+ <ul>
+ <li>prove the feasibility of porting <a href="http://dev.apache.org/">the Apache HTTP server</a> to
+ this platform</li>
+
+ <li>find a "worthy and capable" successor for the venerable
+ <a href="http://www.w3.org/Daemon/">CERN-3.0</a> daemon
+ (which was ported a couple of years ago), and to</li>
+
+ <li>prove that Apache's preforking process model can on this
+ platform easily outperform the accept-fork-serve model used
+ by CERN by a factor of 5 or more.</li>
+ </ul>
+
+ <p>This document serves as a rationale to describe some of the
+ design decisions of the port to this machine.</p>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="design" id="design">Design Goals</a></h2>
+
+
+
+ <p>One objective of the EBCDIC port was to maintain enough
+ backwards compatibility with the (EBCDIC) CERN server to make
+ the transition to the new server attractive and easy. This
+ required the addition of a configurable method to define
+ whether a HTML document was stored in ASCII (the only format
+ accepted by the old server) or in EBCDIC (the native document
+ format in the POSIX subsystem, and therefore the only realistic
+ format in which the other POSIX tools like <code>grep</code> or
+ <code>sed</code> could operate on the documents). The current
+ solution to this is a "pseudo-MIME-format" which is intercepted
+ and interpreted by the Apache server (see below). Future versions
+ might solve the problem by defining an "ebcdic-handler" for all
+ documents which must be converted.</p>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="technical" id="technical">Technical Solution</a></h2>
+
+
+
+ <p>Since all Apache input and output is based upon the BUFF
+ data type and its methods, the easiest solution was to add the
+ conversion to the BUFF handling routines. The conversion must
+ be settable at any time, so a BUFF flag was added which defines
+ whether a BUFF object has currently enabled conversion or not.
+ This flag is modified at several points in the HTTP
+ protocol:</p>
+
+ <ul>
+ <li><strong>set</strong> before a request is received
+ (because the request and the request header lines are always
+ in ASCII format)</li>
+
+ <li><strong>set/unset</strong> when the request body is
+ received - depending on the content type of the request body
+ (because the request body may contain ASCII text or a binary
+ file)</li>
+
+ <li><strong>set</strong> before a reply header is sent
+ (because the response header lines are always in ASCII
+ format)</li>
+
+ <li><strong>set/unset</strong> when the response body is sent
+ - depending on the content type of the response body (because
+ the response body may contain text or a binary file)</li>
+ </ul>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="porting" id="porting">Porting Notes</a></h2>
+
+
+
+ <ol>
+ <li>
+ <p>The relevant changes in the source are <code>#ifdef</code>'ed
+ into two categories:</p>
+
+ <dl>
+ <dt><code><strong>#ifdef
+ CHARSET_EBCDIC</strong></code></dt>
+
+ <dd>
+ <p>Code which is needed for any EBCDIC based machine.
+ This includes character translations, differences in
+ contiguity of the two character sets, flags which
+ indicate which part of the HTTP protocol has to be
+ converted and which part doesn't <em>etc.</em></p>
+ </dd>
+
+ <dt><code><strong>#ifdef _OSD_POSIX</strong></code></dt>
+
+ <dd>
+ <p>Code which is needed for the SIEMENS BS2000/OSD
+ mainframe platform only. This deals with include file
+ differences and socket implementation topics which are
+ only required on the BS2000/OSD platform.</p>
+ </dd>
+ </dl>
+ </li>
+
+ <li>
+ <p>The possibility to translate between ASCII and EBCDIC at
+ the socket level (on BS2000 POSIX, there is a socket option
+ which supports this) was intentionally <em>not</em> chosen,
+ because the byte stream at the HTTP protocol level consists
+ of a mixture of protocol related strings and non-protocol
+ related raw file data. HTTP protocol strings are always
+ encoded in ASCII (the <code>GET</code> request, any Header: lines,
+ the chunking information <em>etc.</em>) whereas the file transfer
+ parts (<em>i.e.</em>, GIF images, CGI output <em>etc.</em>)
+ should usually be just "passed through" by the server. This
+ separation between "protocol string" and "raw data" is
+ reflected in the server code by functions like <code>bgets()</code>
+ or <code>rvputs()</code> for strings, and functions like
+ <code>bwrite()</code> for binary data. A global translation
+ of everything would therefore be inadequate.</p>
+
+ <p>(In the case of text files of course, provisions must be
+ made so that EBCDIC documents are always served in
+ ASCII)</p>
+ </li>
+
+ <li>
+ <p>This port therefore features a built-in protocol level
+ conversion for the server-internal strings (which the
+ compiler translated to EBCDIC strings) and thus for all
+ server-generated documents. The hard coded ASCII escapes
+ <code>\012</code> and <code>\015</code> which are ubiquitous
+ in the server code are an exception: they are already the binary
+ encoding of the ASCII <code>\n</code> and <code>\r</code> and
+ must not be converted to ASCII a second time.
+ This exception is only relevant for server-generated strings;
+ and <em>external</em> EBCDIC documents are not expected to
+ contain ASCII newline characters.</p>
+ </li>
+
+ <li>
+ <p>By examining the call hierarchy for the BUFF management
+ routines, I added an "ebcdic/ascii conversion layer" which
+ would be crossed on every puts/write/get/gets, and a
+ conversion flag which allowed enabling/disabling the
+ conversions on-the-fly. Usually, a document crosses this
+ layer twice from its origin source (a file or CGI output) to
+ its destination (the requesting client): <code>file ->
+ Apache</code>, and <code>Apache -> client</code>.</p>
+
+ <p>The server can now read the header lines of a CGI-script
+ output in EBCDIC format, and then find out that the remainder
+ of the script's output is in ASCII (like in the case of the
+ output of a WWW Counter program: the document body contains a
+ GIF image). All header processing is done in the native
+ EBCDIC format; the server then determines, based on the type
+ of document being served, whether the document body (except
+ for the chunking information, of course) is in ASCII already
+ or must be converted from EBCDIC.</p>
+ </li>
+
+ <li>
+ <p>For Text documents (MIME types text/plain, text/html
+ <em>etc.</em>), an implicit translation to ASCII can be
+ used, or (if the users prefer to store some documents in
+ raw ASCII form for faster serving, or because the files
+ reside on a NFS-mounted directory tree) can be served
+ without conversion.</p>
+
+ <p><strong>Example:</strong></p>
+
+ <p>to serve files with the suffix <code>.ahtml</code> as a
+ raw ASCII <code>text/html</code> document without implicit
+ conversion (and suffix <code>.ascii</code> as ASCII
+ <code>text/plain</code>), use the directives:</p>
+
+ <div class="example"><p><code>
+ AddType text/x-ascii-html .ahtml <br />
+ AddType text/x-ascii-plain .ascii
+ </code></p></div>
+
+ <p>Similarly, any <code>text/foo</code> MIME type can be
+ served as "raw ASCII" by configuring a MIME type
+ "<code>text/x-ascii-foo</code>" for it using
+ <code>AddType</code>.</p>
+ </li>
+
+ <li>
+ <p>Non-text documents are always served "binary" without
+ conversion. This seems to be the most sensible choice for,
+ .<em>e.g.</em>, GIF/ZIP/AU file types. This of course
+ requires the user to copy them to the mainframe host using
+ the "<code>rcp -b</code>" binary switch.</p>
+ </li>
+
+ <li>
+ <p>Server parsed files are always assumed to be in native
+ (<em>i.e.</em>, EBCDIC) format as used on the machine, and
+ are converted after processing.</p>
+ </li>
+
+ <li>
+ <p>For CGI output, the CGI script determines whether a
+ conversion is needed or not: by setting the appropriate
+ Content-Type, text files can be converted, or GIF output can
+ be passed through unmodified. An example for the latter case
+ is the wwwcount program which we ported as well.</p>
+ </li>
+
+ </ol>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="document" id="document">Document Storage Notes</a></h2>
+
+
+
+ <h3><a name="binary" id="binary">Binary Files</a></h3>
+
+
+
+ <p>All files with a <code>Content-Type:</code> which does not
+ start with <code>text/</code> are regarded as <em>binary
+ files</em> by the server and are not subject to any conversion.
+ Examples for binary files are GIF images, gzip-compressed files
+ and the like.</p>
+
+ <p>When exchanging binary files between the mainframe host and
+ a Unix machine or Windows PC, be sure to use the ftp "binary"
+ (<code>TYPE I</code>) command, or use the
+ <code>rcp -b</code> command from the mainframe host (the
+ <code>-b</code> switch is not supported in unix
+ <code>rcp</code>'s).</p>
+
+
+
+ <h3><a name="text" id="text">Text Documents</a></h3>
+
+
+
+ <p>The default assumption of the server is that Text Files
+ (<em>i.e.</em>, all files whose <code>Content-Type:</code>
+ starts with <code>text/</code>) are stored in the native
+ character set of the host, EBCDIC.</p>
+
+
+
+ <h3><a name="ssi" id="ssi">Server Side Included Documents</a></h3>
+
+
+
+ <p>SSI documents must currently be stored in EBCDIC only.
+ No provision is made to convert it from ASCII before
+ processing.</p>
+
+
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="modules" id="modules">Apache Modules' Status</a></h2>
+
+
+
+ <table class="bordered">
+ <tr>
+ <th>Module</th>
+ <th>Status</th>
+ <th>Notes</th>
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/core.html">core</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_access.html">mod_access</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_actions.html">mod_actions</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_asis.html">mod_asis</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_auth.html">mod_auth</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_auth_anon.html">mod_auth_anon</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_auth_dbm.html">mod_auth_dbm</a></code></td>
+ <td align="center">?</td>
+ <td>with own <code>libdb.a</code></td>
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_autoindex.html">mod_autoindex</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_cern_meta.html">mod_cern_meta</a></code></td>
+ <td align="center">?</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_cgi.html">mod_cgi</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_digest.html">mod_digest</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_so.html">mod_so</a></code></td>
+ <td align="center">-</td>
+ <td>no shared libs</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_env.html">mod_env</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_example.html">mod_example</a></code></td>
+ <td align="center">-</td>
+ <td>(test bed only)</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_expires.html">mod_expires</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_imap.html">mod_imap</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_include.html">mod_include</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_info.html">mod_info</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_log_agent.html">mod_log_agent</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_log_config.html">mod_log_config</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_log_referer.html">mod_log_referer</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_mime.html">mod_mime</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_mime_magic.html">mod_mime_magic</a></code></td>
+ <td align="center">?</td>
+ <td>not ported yet</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_negotiation.html">mod_negotiation</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code></td>
+ <td align="center">+</td>
+ <td>untested</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_speling.html">mod_speling</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_status.html">mod_status</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_unique_id.html">mod_unique_id</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_userdir.html">mod_userdir</a></code></td>
+ <td align="center">+</td>
+ <td />
+ </tr>
+
+ <tr>
+ <td align="left"><code class="module"><a href="../mod/mod_usertrack.html">mod_usertrack</a></code></td>
+ <td align="center">?</td>
+ <td>untested</td>
+ </tr>
+ </table>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="third-party" id="third-party">Third Party Modules' Status</a></h2>
+
+
+
+ <table class="bordered">
+ <tr>
+ <th>Module</th>
+ <th>Status</th>
+ <th>Notes</th>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a href="http://java.apache.org/">mod_jserv</a></code></td>
+ <td align="center">-</td>
+ <td>JAVA still being ported.</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a href="http://www.php.net/">mod_php3</a></code></td>
+ <td align="center">+</td>
+ <td><code>mod_php3</code> runs fine, with LDAP and GD
+ and FreeType libraries.</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a href="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">mod_put</a></code></td>
+ <td align="center">?</td>
+ <td>untested</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a href="ftp://hachiman.vidya.com/pub/apache/">mod_session</a></code></td>
+ <td align="center">-</td>
+ <td>untested</td>
+ </tr>
+ </table>
+
+ </div></div><div id="footer"><p class="apache">Maintained by the <a href="http://httpd.apache.org/docs-project/">Apache HTTP Server Documentation Project</a></p><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div></body></html>
\ No newline at end of file
--- /dev/null
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+
+<manualpage>
+ <relativepath href=".." />
+
+ <title>The Apache EBCDIC Port</title>
+
+ <summary>
+
+ <note type="warning"><strong>Warning:</strong> This document
+ has not been updated to take into account changes made in
+ the 2.0 version of the Apache HTTP Server. Some of the
+ information may still be relevant, but please use it with care.
+ </note>
+
+ </summary>
+
+ <section id="overview">
+
+ <title>Overview of the Apache EBCDIC Port</title>
+
+ <p>Version 1.3 of the Apache HTTP Server is the first version
+ which includes a port to a (non-ASCII) mainframe machine which
+ uses the EBCDIC character set as its native codeset.</p>
+
+ <p>(It is the SIEMENS family of mainframes running the <a
+ href="http://www.siemens.de/servers/bs2osd/osdbc_us.htm">BS2000/OSD
+ operating system</a>. This mainframe OS nowadays features a
+ SVR4-derived POSIX subsystem).</p>
+
+ <p>The port was started initially to</p>
+
+ <ul>
+ <li>prove the feasibility of porting <a
+ href="http://dev.apache.org/">the Apache HTTP server</a> to
+ this platform</li>
+
+ <li>find a "worthy and capable" successor for the venerable
+ <a href="http://www.w3.org/Daemon/">CERN-3.0</a> daemon
+ (which was ported a couple of years ago), and to</li>
+
+ <li>prove that Apache's preforking process model can on this
+ platform easily outperform the accept-fork-serve model used
+ by CERN by a factor of 5 or more.</li>
+ </ul>
+
+ <p>This document serves as a rationale to describe some of the
+ design decisions of the port to this machine.</p>
+
+ </section>
+
+ <section id="design">
+
+ <title>Design Goals</title>
+
+ <p>One objective of the EBCDIC port was to maintain enough
+ backwards compatibility with the (EBCDIC) CERN server to make
+ the transition to the new server attractive and easy. This
+ required the addition of a configurable method to define
+ whether a HTML document was stored in ASCII (the only format
+ accepted by the old server) or in EBCDIC (the native document
+ format in the POSIX subsystem, and therefore the only realistic
+ format in which the other POSIX tools like <code>grep</code> or
+ <code>sed</code> could operate on the documents). The current
+ solution to this is a "pseudo-MIME-format" which is intercepted
+ and interpreted by the Apache server (see below). Future versions
+ might solve the problem by defining an "ebcdic-handler" for all
+ documents which must be converted.</p>
+
+ </section>
+
+ <section id="technical">
+
+ <title>Technical Solution</title>
+
+ <p>Since all Apache input and output is based upon the BUFF
+ data type and its methods, the easiest solution was to add the
+ conversion to the BUFF handling routines. The conversion must
+ be settable at any time, so a BUFF flag was added which defines
+ whether a BUFF object has currently enabled conversion or not.
+ This flag is modified at several points in the HTTP
+ protocol:</p>
+
+ <ul>
+ <li><strong>set</strong> before a request is received
+ (because the request and the request header lines are always
+ in ASCII format)</li>
+
+ <li><strong>set/unset</strong> when the request body is
+ received - depending on the content type of the request body
+ (because the request body may contain ASCII text or a binary
+ file)</li>
+
+ <li><strong>set</strong> before a reply header is sent
+ (because the response header lines are always in ASCII
+ format)</li>
+
+ <li><strong>set/unset</strong> when the response body is sent
+ - depending on the content type of the response body (because
+ the response body may contain text or a binary file)</li>
+ </ul>
+
+ </section>
+
+ <section id="porting">
+
+ <title>Porting Notes</title>
+
+ <ol>
+ <li>
+ <p>The relevant changes in the source are <code>#ifdef</code>'ed
+ into two categories:</p>
+
+ <dl>
+ <dt><code><strong>#ifdef
+ CHARSET_EBCDIC</strong></code></dt>
+
+ <dd>
+ <p>Code which is needed for any EBCDIC based machine.
+ This includes character translations, differences in
+ contiguity of the two character sets, flags which
+ indicate which part of the HTTP protocol has to be
+ converted and which part doesn't <em>etc.</em></p>
+ </dd>
+
+ <dt><code><strong>#ifdef _OSD_POSIX</strong></code></dt>
+
+ <dd>
+ <p>Code which is needed for the SIEMENS BS2000/OSD
+ mainframe platform only. This deals with include file
+ differences and socket implementation topics which are
+ only required on the BS2000/OSD platform.</p>
+ </dd>
+ </dl>
+ </li>
+
+ <li>
+ <p>The possibility to translate between ASCII and EBCDIC at
+ the socket level (on BS2000 POSIX, there is a socket option
+ which supports this) was intentionally <em>not</em> chosen,
+ because the byte stream at the HTTP protocol level consists
+ of a mixture of protocol related strings and non-protocol
+ related raw file data. HTTP protocol strings are always
+ encoded in ASCII (the <code>GET</code> request, any Header: lines,
+ the chunking information <em>etc.</em>) whereas the file transfer
+ parts (<em>i.e.</em>, GIF images, CGI output <em>etc.</em>)
+ should usually be just "passed through" by the server. This
+ separation between "protocol string" and "raw data" is
+ reflected in the server code by functions like <code>bgets()</code>
+ or <code>rvputs()</code> for strings, and functions like
+ <code>bwrite()</code> for binary data. A global translation
+ of everything would therefore be inadequate.</p>
+
+ <p>(In the case of text files of course, provisions must be
+ made so that EBCDIC documents are always served in
+ ASCII)</p>
+ </li>
+
+ <li>
+ <p>This port therefore features a built-in protocol level
+ conversion for the server-internal strings (which the
+ compiler translated to EBCDIC strings) and thus for all
+ server-generated documents. The hard coded ASCII escapes
+ <code>\012</code> and <code>\015</code> which are ubiquitous
+ in the server code are an exception: they are already the binary
+ encoding of the ASCII <code>\n</code> and <code>\r</code> and
+ must not be converted to ASCII a second time.
+ This exception is only relevant for server-generated strings;
+ and <em>external</em> EBCDIC documents are not expected to
+ contain ASCII newline characters.</p>
+ </li>
+
+ <li>
+ <p>By examining the call hierarchy for the BUFF management
+ routines, I added an "ebcdic/ascii conversion layer" which
+ would be crossed on every puts/write/get/gets, and a
+ conversion flag which allowed enabling/disabling the
+ conversions on-the-fly. Usually, a document crosses this
+ layer twice from its origin source (a file or CGI output) to
+ its destination (the requesting client): <code>file ->
+ Apache</code>, and <code>Apache -> client</code>.</p>
+
+ <p>The server can now read the header lines of a CGI-script
+ output in EBCDIC format, and then find out that the remainder
+ of the script's output is in ASCII (like in the case of the
+ output of a WWW Counter program: the document body contains a
+ GIF image). All header processing is done in the native
+ EBCDIC format; the server then determines, based on the type
+ of document being served, whether the document body (except
+ for the chunking information, of course) is in ASCII already
+ or must be converted from EBCDIC.</p>
+ </li>
+
+ <li>
+ <p>For Text documents (MIME types text/plain, text/html
+ <em>etc.</em>), an implicit translation to ASCII can be
+ used, or (if the users prefer to store some documents in
+ raw ASCII form for faster serving, or because the files
+ reside on a NFS-mounted directory tree) can be served
+ without conversion.</p>
+
+ <p><strong>Example:</strong></p>
+
+ <p>to serve files with the suffix <code>.ahtml</code> as a
+ raw ASCII <code>text/html</code> document without implicit
+ conversion (and suffix <code>.ascii</code> as ASCII
+ <code>text/plain</code>), use the directives:</p>
+
+ <example>
+ AddType text/x-ascii-html .ahtml <br />
+ AddType text/x-ascii-plain .ascii
+ </example>
+
+ <p>Similarly, any <code>text/foo</code> MIME type can be
+ served as "raw ASCII" by configuring a MIME type
+ "<code>text/x-ascii-foo</code>" for it using
+ <code>AddType</code>.</p>
+ </li>
+
+ <li>
+ <p>Non-text documents are always served "binary" without
+ conversion. This seems to be the most sensible choice for,
+ .<em>e.g.</em>, GIF/ZIP/AU file types. This of course
+ requires the user to copy them to the mainframe host using
+ the "<code>rcp -b</code>" binary switch.</p>
+ </li>
+
+ <li>
+ <p>Server parsed files are always assumed to be in native
+ (<em>i.e.</em>, EBCDIC) format as used on the machine, and
+ are converted after processing.</p>
+ </li>
+
+ <li>
+ <p>For CGI output, the CGI script determines whether a
+ conversion is needed or not: by setting the appropriate
+ Content-Type, text files can be converted, or GIF output can
+ be passed through unmodified. An example for the latter case
+ is the wwwcount program which we ported as well.</p>
+ </li>
+
+ </ol>
+
+ </section>
+
+ <section id="document">
+
+ <title>Document Storage Notes</title>
+
+ <section id="binary">
+
+ <title>Binary Files</title>
+
+ <p>All files with a <code>Content-Type:</code> which does not
+ start with <code>text/</code> are regarded as <em>binary
+ files</em> by the server and are not subject to any conversion.
+ Examples for binary files are GIF images, gzip-compressed files
+ and the like.</p>
+
+ <p>When exchanging binary files between the mainframe host and
+ a Unix machine or Windows PC, be sure to use the ftp "binary"
+ (<code>TYPE I</code>) command, or use the
+ <code>rcp -b</code> command from the mainframe host (the
+ <code>-b</code> switch is not supported in unix
+ <code>rcp</code>'s).</p>
+
+ </section>
+
+ <section id="text">
+
+ <title>Text Documents</title>
+
+ <p>The default assumption of the server is that Text Files
+ (<em>i.e.</em>, all files whose <code>Content-Type:</code>
+ starts with <code>text/</code>) are stored in the native
+ character set of the host, EBCDIC.</p>
+
+ </section>
+
+ <section id="ssi">
+
+ <title>Server Side Included Documents</title>
+
+ <p>SSI documents must currently be stored in EBCDIC only.
+ No provision is made to convert it from ASCII before
+ processing.</p>
+
+ </section>
+
+ </section>
+
+ <section id="modules">
+
+ <title>Apache Modules' Status</title>
+
+ <table border="1" align="center">
+ <tr>
+ <th>Module</th>
+ <th>Status</th>
+ <th>Notes</th>
+ </tr>
+
+ <tr>
+ <td align="left"><module>core</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_access</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_actions</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_alias</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_asis</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_auth</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_auth_anon</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_auth_dbm</module></td>
+ <td align="center">?</td>
+ <td>with own <code>libdb.a</code></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_autoindex</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_cern_meta</module></td>
+ <td align="center">?</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_cgi</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_digest</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_dir</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_so</module></td>
+ <td align="center">-</td>
+ <td>no shared libs</td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_env</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_example</module></td>
+ <td align="center">-</td>
+ <td>(test bed only)</td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_expires</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_headers</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_imap</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_include</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_info</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_log_agent</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_log_config</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_log_referer</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_mime</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_mime_magic</module></td>
+ <td align="center">?</td>
+ <td>not ported yet</td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_negotiation</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_proxy</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_rewrite</module></td>
+ <td align="center">+</td>
+ <td>untested</td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_setenvif</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_speling</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_status</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_unique_id</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_userdir</module></td>
+ <td align="center">+</td>
+ <td></td>
+ </tr>
+
+ <tr>
+ <td align="left"><module>mod_usertrack</module></td>
+ <td align="center">?</td>
+ <td>untested</td>
+ </tr>
+ </table>
+
+ </section>
+
+ <section id="third-party">
+
+ <title>Third Party Modules' Status</title>
+
+ <table border="1" align="center">
+ <tr>
+ <th>Module</th>
+ <th>Status</th>
+ <th>Notes</th>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a
+ href="http://java.apache.org/"
+ >mod_jserv</a></code></td>
+ <td align="center">-</td>
+ <td>JAVA still being ported.</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a href="http://www.php.net/"
+ >mod_php3</a></code></td>
+ <td align="center">+</td>
+ <td><code>mod_php3</code> runs fine, with LDAP and GD
+ and FreeType libraries.</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a
+ href="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html"
+ >mod_put</a></code></td>
+ <td align="center">?</td>
+ <td>untested</td>
+ </tr>
+
+ <tr>
+ <td align="left"><code><a
+ href="ftp://hachiman.vidya.com/pub/apache/"
+ >mod_session</a></code></td>
+ <td align="center">-</td>
+ <td>untested</td>
+ </tr>
+ </table>
+
+ </section>
+
+</manualpage>
+
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ --><title>Platform Specific Notes - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body id="manual-page"><div id="page-header"><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.0</a></div><div id="page-content"><div id="preamble"><h1>Platform Specific Notes</h1></div><div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#win">Microsoft Windows</a></li><li><img alt="" src="../images/down.gif" /> <a href="#other">Other Platforms</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="win" id="win">Microsoft Windows</a></h2>
+
+
+
+ <dl>
+ <dt>Using Apache</dt>
+ <dd>
+ <p>This document explains how to install, configure and run Apache 2.0
+ under Microsoft Windows.</p>
+
+ <p>See: <a href="windows.html">Using Apache with Microsoft Windows</a></p>
+ </dd>
+ </dl>
+
+ <dl>
+ <dt>Running Apache as a Service</dt>
+ <dd>
+ <p>Apache can be run as a service on Windows NT/2000.</p>
+
+ <p>See: <a href="win_service.html">Running Apache for Windows as a Service</a></p>
+ </dd>
+ </dl>
+
+ <dl>
+ <dt>Compiling Apache</dt>
+ <dd>
+ <p>There are many important points before you begin compiling Apache.
+ This document explain them.</p>
+
+ <p>See: <a href="win_compiling.html">Compiling Apache for Microsoft Windows</a></p>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="other" id="other">Other Platforms</a></h2>
+
+
+
+ <dl>
+ <dt>Novell NetWare</dt>
+ <dd>
+ <p>This document explains how to install, configure and run Apache 2.0
+ under Novell NetWare 5.1 and above.</p>
+
+ <p>See: <a href="netware.html">Using Apache With Novell NetWare</a></p>
+ </dd>
+ </dl>
+
+ <dl>
+ <dt>EBCDIC</dt>
+ <dd>
+ <p>Version 1.3 of the Apache HTTP Server is the first version which
+ includes a port to a (non-ASCII) mainframe machine which uses the
+ EBCDIC character set as its native codeset.</p>
+
+ <div class="warning"><strong>Warning:</strong> This document
+ has not been updated to take into account changes made in
+ the 2.0 version of the Apache HTTP Server. Some of the
+ information may still be relevant, but please use it
+ with care.</div>
+
+ <p>See: <a href="ebcdic.html">The Apache EBCDIC Port</a></p>
+ </dd>
+ </dl>
+
+ </div></div><div id="footer"><p class="apache">Maintained by the <a href="http://httpd.apache.org/docs-project/">Apache HTTP Server Documentation Project</a></p><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div></body></html>
\ No newline at end of file
--- /dev/null
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+
+<manualpage>
+ <relativepath href=".." />
+
+ <title>Platform Specific Notes</title>
+
+ <section id="win">
+
+ <title>Microsoft Windows</title>
+
+ <dl>
+ <dt>Using Apache</dt>
+ <dd>
+ <p>This document explains how to install, configure and run Apache 2.0
+ under Microsoft Windows.</p>
+
+ <p>See: <a href="windows.html">Using Apache with Microsoft Windows</a></p>
+ </dd>
+ </dl>
+
+ <dl>
+ <dt>Running Apache as a Service</dt>
+ <dd>
+ <p>Apache can be run as a service on Windows NT/2000.</p>
+
+ <p>See: <a href="win_service.html"
+ >Running Apache for Windows as a Service</a></p>
+ </dd>
+ </dl>
+
+ <dl>
+ <dt>Compiling Apache</dt>
+ <dd>
+ <p>There are many important points before you begin compiling Apache.
+ This document explain them.</p>
+
+ <p>See: <a href="win_compiling.html"
+ >Compiling Apache for Microsoft Windows</a></p>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="other">
+
+ <title>Other Platforms</title>
+
+ <dl>
+ <dt>Novell NetWare</dt>
+ <dd>
+ <p>This document explains how to install, configure and run Apache 2.0
+ under Novell NetWare 5.1 and above.</p>
+
+ <p>See: <a href="netware.html">Using Apache With Novell NetWare</a></p>
+ </dd>
+ </dl>
+
+ <dl>
+ <dt>EBCDIC</dt>
+ <dd>
+ <p>Version 1.3 of the Apache HTTP Server is the first version which
+ includes a port to a (non-ASCII) mainframe machine which uses the
+ EBCDIC character set as its native codeset.</p>
+
+ <note type="warning"><strong>Warning:</strong> This document
+ has not been updated to take into account changes made in
+ the 2.0 version of the Apache HTTP Server. Some of the
+ information may still be relevant, but please use it
+ with care.</note>
+
+ <p>See: <a href="ebcdic.html">The Apache EBCDIC Port</a></p>
+ </dd>
+ </dl>
+
+ </section>
+
+</manualpage>
\ No newline at end of file
projects / apache / commitdiff