httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jor...@apache.org
Subject cvs commit: httpd-2.0/docs/manual/ssl ssl_compat.xml
Date Thu, 03 Jun 2004 10:16:12 GMT
jorton      2004/06/03 03:16:12

  Modified:    docs/manual/ssl ssl_compat.xml
  Log:
  Fix links and update content in introduction.  Update page content to
  reflect that mod_ssl in 2.0 doesn't actually provide the most of the
  backwards-compat hooks; leave it as a guide for migration.
  
  Revision  Changes    Path
  1.11      +36 -43    httpd-2.0/docs/manual/ssl/ssl_compat.xml
  
  Index: ssl_compat.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_compat.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -d -w -u -r1.10 -r1.11
  --- ssl_compat.xml	17 Apr 2004 11:18:05 -0000	1.10
  +++ ssl_compat.xml	3 Jun 2004 10:16:12 -0000	1.11
  @@ -32,37 +32,35 @@
   </blockquote>
   
   <p>
  -Here we talk about backward compatibility to other SSL solutions. As you
  -perhaps know, mod_ssl is not the only existing SSL solution for Apache.
  -Actually there are four additional major products available on the market: Ben
  -Laurie's freely available <a href="http://www.apache-ssl.org/">Apache-SSL</a>
  -(from where mod_ssl were originally derived in 1998), Red Hat's commercial <a
  -href="http://www.redhat.com/products/product-details.phtml?id=rhsa">Secure Web
  -Server</a> (which is based on mod_ssl), Covalent's commercial <a
  -href="http://raven.covalent.net/">Raven SSL Module</a> (also based on mod_ssl)
  -and finally C2Net's commercial product <a
  -href="http://www.c2.net/products/stronghold/">Stronghold</a> (based on a
  -different evolution branch named Sioux up to Stronghold 2.x and based on
  -mod_ssl since Stronghold 3.x).</p>
  +This page covers backwards compatibility between mod_ssl and other
  +SSL solutions.  mod_ssl is not the only SSL solution for Apache; four
  +additional products are (or were) also available: Ben Laurie's freely
  +available <a href="http://www.apache-ssl.org/">Apache-SSL</a> (from
  +where mod_ssl were originally derived in 1998), Red Hat's commercial
  +<a
  +href="http://www.redhat.com/products/product-details.phtml?id=rhsa">Secure
  +Web Server</a> (which was based on mod_ssl), Covalent's commercial <a
  +href="http://www.covalent.net/">Raven SSL Module</a> (also based on
  +mod_ssl) and finally C2Net's (now Red Hat's) commercial product <a
  +href="http://www.redhat.com/explore/stronghold/">Stronghold</a> (based
  +on a different evolution branch named Sioux up to Stronghold 2.x and
  +based on mod_ssl since Stronghold 3.x).</p>
   
   <p>
  -The idea in mod_ssl is mainly the following: because mod_ssl provides mostly a
  -superset of the functionality of all other solutions we can easily provide
  -backward compatibility for most of the cases. Actually there are three
  -compatibility areas we currently address: configuration directives,
  -environment variables and custom log functions.</p>   
  +mod_ssl mostly provides a superset of the functionality of all other
  +solutions, so it's simple to migrate from one of the older modules to
  +mod_ssl. The configuration directives and environment variable names
  +used by the older SSL solutions vary from those used in mod_ssl;
  +tables are included here to give the equivalents used by mod_ssl to
  +allow easy migration. .</p>
   </summary>
   
   <section id="configuration"><title>Configuration Directives</title>
  -<p>For backward compatibility to the configuration directives of other SSL
  -solutions we do an on-the-fly mapping: directives which have a direct
  -counterpart in mod_ssl are mapped silently while other directives lead to a
  -warning message in the logfiles. The currently implemented directive mapping
  -is listed in <a href="#table1">Table 1</a>. Currently full backward
  -compatibility is provided only for Apache-SSL 1.x and mod_ssl 2.0.x.
  -Compatibility to Sioux 1.x and Stronghold 2.x is only partial because of
  -special functionality in these interfaces which mod_ssl (still) doesn't
  -provide.</p>
  +<p>The mapping between configuration directives used by Apache-SSL
  +1.x and mod_ssl 2.0.x is given in <a href="#table1">Table
  +1</a>. The mapping from Sioux 1.x and Stronghold 2.x is only partial
  +because of special functionality in these interfaces which mod_ssl
  +doesn't provide.</p>
   
   
   <section id="table1">
  @@ -113,10 +111,10 @@
   
   <tr><td><code>SSL_LogX509Attributes</code> <em>arg</em></td><td>-</td><td>functionality
not supported</td></tr>
   <tr><th colspan="3">Stronghold 2.x compatibility:</th></tr>
  -<tr><td><code>StrongholdAccelerator</code> <em>dir</em></td><td>-</td><td>functionality
not supported</td></tr>
  -<tr><td><code>StrongholdKey</code> <em>dir</em></td><td>-</td><td>functionality
not supported</td></tr>
  +<tr><td><code>StrongholdAccelerator</code> <em>engine</em></td><td><code>SSLCryptoDevice</code>
<em>engine</em></td><td>renamed</td></tr>
  +<tr><td><code>StrongholdKey</code> <em>dir</em></td><td>-</td><td>functionality
not needed</td></tr>
   
  -<tr><td><code>StrongholdLicenseFile</code> <em>dir</em></td><td>-</td><td>functionality
not supported</td></tr>
  +<tr><td><code>StrongholdLicenseFile</code> <em>dir</em></td><td>-</td><td>functionality
not needed</td></tr>
   <tr><td><code>SSLFlag</code> <em>flag</em></td><td><code>SSLEngine</code>
<em>flag</em></td><td>renamed</td></tr>
   <tr><td><code>SSLSessionLockFile</code> <em>file</em></td><td><code>SSLMutex</code>
<em>file</em></td><td>renamed</td></tr>
   
  @@ -129,22 +127,18 @@
   <tr><td><code>AuthCertDir</code> <em>dir</em></td><td>-</td><td>functionality
not supported</td></tr>
   
   <tr><td><code>SSL_Group</code> <em>name</em></td><td>-</td><td>functionality
not supported</td></tr>
  -<tr><td><code>SSLProxyMachineCertPath</code> <em>dir</em></td><td>-</td><td>functionality
not supported</td></tr>
  -<tr><td><code>SSLProxyMachineCertFile</code> <em>file</em></td><td>-</td><td>functionality
not supported</td></tr>
  -
  -<tr><td><code>SSLProxyCACertificatePath</code> <em>dir</em></td><td>-</td><td>functionality
not supported</td></tr>
  -<tr><td><code>SSLProxyCACertificateFile</code> <em>file</em></td><td>-</td><td>functionality
not supported</td></tr>
  -<tr><td><code>SSLProxyVerifyDepth</code> <em>number</em></td><td>-</td><td>functionality
not supported</td></tr>
  +<tr><td><code>SSLProxyMachineCertPath</code> <em>dir</em></td><td><code>SSLProxyMachineCertificatePath</code>
<em>dir</em></td><td>renamed</td></tr>
  +<tr><td><code>SSLProxyMachineCertFile</code> <em>file</em></td><td><code>SSLProxyMachineCertificateFile</code>
<em>file</em></td><td>renamed</td></tr>
   
  -<tr><td><code>SSLProxyCipherList</code> <em>spec</em></td><td>-</td><td>functionality
not supported</td></tr>
  +<tr><td><code>SSLProxyCipherList</code> <em>spec</em></td><td><code>SSLProxyCipherSpec</code>
<em>spec</em></td><td>renamed</td></tr>
   </table>
   </section>
   </section>
   
   <section id="variables"><title>Environment Variables</title>
  -<p>When you use ``<code>SSLOptions +CompatEnvVars</code>'' additional
environment
  -variables are generated. They all correspond to existing official mod_ssl
  -variables. The currently implemented variable derivation is listed in <a
  +
  +<p>The mapping between environment variable names used by the older
  +SSL solutions and the names used by mod_ssl is given in <a
   href="#table2">Table 2</a>.</p>
   
   <section id="table2">
  @@ -237,8 +231,7 @@
   
   <section id="customlog"><title>Custom Log Functions</title>
   <p>
  -When mod_ssl is built into Apache or at least loaded (under DSO situation)
  -additional functions exist for the <a
  +When mod_ssl is enabled, additional functions exist for the <a
   href="../mod/mod_log_config.html#formats">Custom Log Format</a> of
   <module>mod_log_config</module> as documented in the Reference
   Chapter. Beside the ``<code>%{</code><em>varname</em><code>}x</code>''
  
  
  

Mime
View raw message