www/apache
1
0
Fork 0
mirror of https://github.com/apache/httpd.git synced 2026-01-06 09:01:14 +03:00
Code Activity

Update transforms now that xslt is working again.

Browse Source 
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@99475 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Joshua Slive
2003-04-21 14:57:50 +00:00
parent ce1a09a8e0
commit 8cdf4feadd
2 changed files with 103 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/manual/mod/core.html.en
View File

@@ -1708,13 +1708,25 @@ URLs</td></tr>
limits the scope of the enclosed directives by URL. It is similar to the
<code class="directive"><a href="#directory">&lt;Directory&gt;</a></code>
directive, and starts a subsection which is terminated with a
<code>&lt;/Location&gt;</code> directive. <code class="directive">&lt;Location&gt;</code> sections are processed in the
<code>&lt;/Location&gt;</code> directive. <code class="directive">&lt;Location&gt;</code> sections are processed in the
order they appear in the configuration file, after the <code class="directive"><a href="#directory">&lt;Directory&gt;</a></code> sections and
<code>.htaccess</code> files are read, and after the <code class="directive"><a href="#files">&lt;Files&gt;</a></code> sections.</p>
<p>Note that URLs do not have to line up with the filesystem at
all, it should be emphasized that <code class="directive">&lt;Location&gt;</code> operates completely
outside the filesystem.</p>
<p><code class="directive">&lt;Location&gt;</code> sections operate
completely outside the filesystem. This has several consequences.
Most importantly, <code class="directive">&lt;Location&gt;</code>
directives should not be used to control access to filesystem
locations. Since several different URLs may map to the same
filesystem location, such access controls may by circumvented.</p>
<div class="note"><h3>When to use <code class="directive">&lt;Location&gt;</code></h3>
<p>Use <code class="directive">&lt;Location&gt;</code> to apply
directives to content that lives outside the filesystem. For
content that lives in the filesystem, use <code class="directive"><a href="#directory">&lt;Directory&gt;</a></code> and <code class="directive"><a href="#files">&lt;Files&gt;</a></code>. An exception is
<code>&lt;Location /&gt;</code>, which is an easy way to
apply a configuration to the entire server.</p>
</div>
<p>For all origin (non-proxy) requests, the URL to be matched is a
URL-path of the form <code>/path/</code>. No scheme, hostname,

103
docs/manual/mod/mod_dav.html.en
View File

@@ -42,6 +42,8 @@
<h3>Topics</h3>
<ul id="topics">
<li><img alt="" src="../images/down.gif" /> <a href="#example">Enabling WebDAV</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#security">Security Issues</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#complex">Complex Configurations</a></li>
</ul><h3>See also</h3>
<ul class="seealso">
<li><code class="directive"><a href="../mod/mod_dav_fs.html#davlockdb">DavLockDB</a></code></li>
@@ -56,19 +58,29 @@
<div class="example"><p><code>Dav On</code></p></div>
<p>This enables the DAV file system provider, which is implemented by
the <code class="module"><a href="../mod/mod_dav_fs.html">mod_dav_fs</a></code> module. Therefore that module has to
be compiled into the server or has to be loaded at runtime using the
<p>This enables the DAV file system provider, which is implemented
by the <code class="module"><a href="../mod/mod_dav_fs.html">mod_dav_fs</a></code> module. Therefore, that module
must be compiled into the server or loaded at runtime using the
<code class="directive"><a href="../mod/mod_so.html#loadmodule">LoadModule</a></code> directive.</p>
<p>In order to make it work you have to specify a web-server writable
filename for the DAV lock database by adding the following to the
global section in your <code>httpd.conf</code> file:</p>
<p>In addition, a location for the DAV lock database must be
specified in the global section of your <code>httpd.conf</code>
file:</p>
<div class="example"><p><code>
DavLockDB /tmp/DavLock
DavLockDB /usr/local/apache2/var/DavLock
</code></p></div>
<p>The directory containing the lock database file must be
writable by the <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code>
and <code class="directive"><a href="../mod/mpm_common.html#group">Group</a></code> under which
Apache is running. For security reasons, you should create a
directory for this purpose rather than changing the permissions on
an existing directory. In the above example, Apache will create
files in the <code>/usr/local/apache2/var/</code> directory
with the base filename <code>DavLock</code> and extension name
chosen by the server.</p>
<p>You may wish to add a <code class="directive"><a href="../mod/core.html#limit">&lt;Limit&gt;</a></code> clause inside the <code class="directive"><a href="../mod/core.html#location">&lt;Location&gt;</a></code> directive to limit access to
DAV-enabled locations. If you want to set the maximum amount of
bytes that a DAV client can send at one request, you have to use
@@ -87,7 +99,7 @@
AuthName DAV<br />
AuthUserFile user.passwd<br />
<br />
&lt;LimitExcept GET HEAD OPTIONS&gt;<br />
&lt;LimitExcept GET OPTIONS&gt;<br />
<span class="indent">
require user admin<br />
</span>
@@ -96,14 +108,73 @@
&lt;/Location&gt;<br />
</code></p></div>
<div class="warning"><h3>Security</h3>
<p>The use of HTTP Basic Authentication is not recommended. You
should use at least HTTP Digest Authentication, which is provided by
the <code class="module"><a href="../mod/mod_auth_digest.html">mod_auth_digest</a></code> module. Nearly all WebDAV clients
support this authentication method. Of course, Basic Authentication
over an <a href="../ssl/">SSL</a> enabled connection is secure,
too.</p>
</div>
<p><code class="module"><a href="../mod/mod_dav.html">mod_dav</a></code> is a descendent of Greg Stein's <a href="http://www.webdav.org/mod_dav/">mod_dav for Apache 1.3</a>. More
information about the module is available from that site.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="security" id="security">Security Issues</a></h2>
<p>Since DAV access methods allow remote clients to manipulate
files on the server, you must take particular care to assure that
your server is secure before enabling <code class="module"><a href="../mod/mod_dav.html">mod_dav</a></code>.</p>
<p>Any location on the server where DAV is enabled should be
protected by authentication. The use of HTTP Basic Authentication
is not recommended. You should use at least HTTP Digest
Authentication, which is provided by the
<code class="module"><a href="../mod/mod_auth_digest.html">mod_auth_digest</a></code> module. Nearly all WebDAV clients
support this authentication method. An alternative is Basic
Authentication over an <a href="../ssl/">SSL</a> enabled
connection.</p>
<p>In order for <code class="module"><a href="../mod/mod_dav.html">mod_dav</a></code> to manage files, it must
be able to write to the directories and files under its control
using the <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code> and
<code class="directive"><a href="../mod/mpm_common.html#group">Group</a></code> under which
Apache is running. New files created will also be owned by this
<code class="directive"><a href="../mod/mpm_common.html#user">User</a></code> and <code class="directive"><a href="../mod/mpm_common.html#group">Group</a></code>. For this reason, it is
important to control access to this account. The DAV repository
is considered private to Apache; modifying files outside of Apache
(for example using FTP or filesystem-level tools) should not be
allowed.</p>
<p><code class="module"><a href="../mod/mod_dav.html">mod_dav</a></code> may be subject to various kinds of
denial-of-service attacks. The <code class="directive"><a href="../mod/core.html#limitxmlrequestbody">LimitXMLRequestBody</a></code> directive can be
used to limit the amount of memory consumed in parsing large DAV
requests. The <code class="directive"><a href="#davdepthinfinity">DavDepthInfinity</a></code> directive can be
used to prevent <code>PROPFIND</code> requests on a very large
repository from consuming large amounts of memory. Another
possible denial-of-service attack involves a client simply filling
up all available disk space with many large files. There is no
direct way to prevent this in Apache, so you should avoid giving
DAV access to untrusted users.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="complex" id="complex">Complex Configurations</a></h2>
<p>One common request is to use <code class="module"><a href="../mod/mod_dav.html">mod_dav</a></code> to
manipulate dynamic files (PHP scripts, CGI scripts, etc). This is
difficult because a <code>GET</code> request will always run the
script, rather than downloading its contents. One way to avoid
this is to map two different URLs to the content, one of which
will run the script, and one of which will allow it to be
downloaded and manipulated with DAV.</p>
<div class="example"><p><code>
Alias /phparea /home/gstein/php_files<br />
Alias /php-source /home/gstein/php_files<br />
&lt;Location /php-source&gt;
<span class="indent">
DAV On<br />
ForceType text/plain<br />
</span>
&lt;/Location&gt;
</code></p></div>
<p>With this setup, <code>http://example.com/phparea</code> can be
used to access the output of the PHP scripts, and
<code>http://example.com/php-source</code> can be used with a DAV
client to manipulate them.</p>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="Dav" id="Dav">Dav</a> <a name="dav" id="dav">Directive</a></h2>