blob: eda804c03f9ebc9fb7130f32f90505327284a110 [file] [log] [blame]
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
<!-- $LastChangedRevision$ -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="new_api_2_6.xml.meta">
<title>API Changes in Apache HTTP Server 2.6 since 2.4</title>
<summary>
<p>This document describes changes to the Apache HTTPD API from
version 2.4 to 2.6, that may be of interest to module/application
developers and core hacks. As of the first GA release of the
2.6 branch API compatibility is preserved for the life of the
2.6 branch. (The
<a href="http://svn.apache.org/repos/asf/httpd/httpd/branches/2.6.x/VERSIONING">VERSIONING</a>
description for the 2.6 release provides more information about API
compatibility.)</p>
<p>API changes fall into two categories: APIs that are altogether new,
and existing APIs that are expanded or changed. The latter are
further divided into those where all changes are backwards-compatible
(so existing modules can ignore them), and those that might
require attention by maintainers. As with the transition from
HTTPD 2.2 to 2.4, existing modules and applications will require
recompiling and may call for some attention, but most should not
require any substantial updating (although some may be able to
take advantage of API changes to offer significant improvements).</p>
<p>For the purpose of this document, the API is split according
to the public header files. These headers are themselves the
reference documentation, and can be used to generate a browsable
HTML reference with <code>make docs</code>.</p>
</summary>
<section id="api_changes">
<title>Changed APIs</title>
<section id="ap_fill_me_in">
<title>ap_fill_me_in (NEW!)</title>
<p>Introduces a new API to fill me in.</p>
</section>
<section id="http_request">
<title>http_request (changed)</title>
<ul>
<li>New autht_provider API</li>
<li>New <code>token_checker</code> hook to handle authentication based on
mechanisms other than username and password.</li>
<li>New function <code>ap_hook_check_autht</code>, as an addition to
<code>ap_hook_check_authn</code> and <code>ap_hook_check_authz</code>.</li>
</ul>
</section>
<section id="mod_auth">
<title>mod_auth (changed)</title>
<p>Adds an additional provider framework for autht - token authentication.</p>
</section>
</section>
<section id="upgrading">
<title>Specific information on upgrading modules from 2.4</title>
<section id="upgrading_fillmein">
<title>Fill me in</title>
<p>In order to take advantage of fill me in.</p>
</section>
<section id="upgrading_byfunction">
<title>If your module uses these existing APIs...</title>
<dl>
<dt><code>ap_md5digest()</code> / <code>ap_md5contextTo64</code></dt>
<dd>These functions are no longer available. Use the equivalent functions
from APR if needed.</dd>
</dl>
</section>
<section id="upgrading_byfeature">
<title>If your module interfaces with this feature...</title>
<dl>
<dt>fillmin</dt>
<dd>Optional: If your module fills me in.</dd>
</dl>
</section>
<section id="upgrading_newfeatures">
<title>Does your module...</title>
<dl>
<dt>Fill me in</dt>
<dd>Consider if filling me in.</dd>
</dl>
</section>
</section>
</manualpage>